Segmentation fault (core dumped)

>Segmentation fault (core dumped)

Attached: mrkrabs.jpg (680x464, 38K)

Just use gdb

Just use printf

Just use Windows

Just patch it

Just be yourself

Just use macOS

just do it

>dinamically allocating memory for matrices in C
>int ** m = (int **) malloc(N*M*sizeof(int));

I spent more than I want to admit until I noticed

Use valgrind

just copy something from stackoverflow

just

This is why UNIX sucks. Portability was a mistake.

On Windows, you'll instead get something along the lines of "program has stopped responding" when a program segfaults. It's still a segfault, however.

This is what I like aboutg C. Those who persevere become more careful programmers.

I have a lot to say about this and difficulty in programming in general, but, well, you definitely won't see soyboys programming in C.

Attached: 11148475_10205888481678644_7077897536686671709_o.jpg (1365x1365, 177K)

>Trying to reach an area of memory not belonging to you.
What are you, a thief?

Attached: 1503267527238.gif (192x224, 42K)

manage your memory better retard

Your autism know no bounds, user.

Attached: hqdefault.jpg (480x360, 20K)

just use LLDB

just use Ruby

this

give it back op

Xorg :0 -configure
Segmentation fault

Fucking arch.

just use java

>NullPointerException

>Those who persevere, live on to contribute industry crippling attack vectors to malicious actors around the world
ftfy

>casting malloc
>in C

Attached: 1522789179283.gif (351x398, 113K)

give it back jamal

>./a
>bash: a: No such file or directory
>ls
>a

Observe the only specimen on Jow Forums that got beyond hello world in C.

>chmod +x a
I think there's an obscure reason why it says that. Pretty sure that it's a bug that got promoted to a feature tho.

It says that when it's not compiled on the same architecture as it's running (64bit executable on 32bit machine)

(Correct me if I said that wrong, I'm having trouble finding the right words rn)

protected mode was a mistake

m68k will rise again

this

>purchased Ryzen
everyone point and laff.

Yeah, you can't run a 64-bit program on a 32-bit system; however, you can do it the other way around.

It happens when the program requests to be loaded using a dynamic linker that doesn't exist on your system. The kernel tries to open the requested linker, fails, and reports the "file not found" error back to userspace.

32 vs. 64 bit issues come from the fact that the dynamic linker has a different name on each architecture (ld-linux.so.2 vs. ld-linux-x86-64.so.2).