Penguin
Note: You are viewing an old revision of this page. View the current version.

My program causes a "Segmentation Fault" in malloc(3) or new

It's common for a program to cause a "Segmentation Fault" in new or malloc(3) if you have previously corrupted memory by using a pointer incorrectly.

To diagnose this problem, compile everything with -g (and probably -Wall as well) and link it all with electric fence (-lefence).

eg
gcc -g -Wall broken.cc -o broken.o
gcc -lefence broken.o -o broken

Check your ulimit(1) is not set to 0 (as is the default on most recent distros).

ulimit -c unlimited

This allows your program to dump core.

then run your program

 ./broken
 Segmentation Fault (core dumped)

If you don't get the "(core dumped)" bit, then your ulimit is wrong, or you don't have write access to the current working directory, or the disk is full etc.

Now that you have the program and the core file, use it to figure out where your program cored

gdb ./broken ./core

gdb will mutter on about stuff, if it says "(no symbols)" then you didn't compile with -g above. Then at the (gdb) prompt type "bt full"

(gdb) bt full

bt full will take the back trace of the core file and if you specify "full" it'll show you all the variables along the way.

The first line should be the place where your bug occured. If you look at this line you'll probably find you're doing something silly (like addressing past the end of an array, or using a pointer that has been free()'d).

ld: name: hidden symbol `__dso_handle' in /.../crtbegin.o is referenced by DSO

You are linking against a shared library that was created incorrectly.

Eg this happens with gcc/g++ version 3 if you create a shared library directly using

ld -shared -o libfoo.so ...

You should instead use

g++ -shared -Wl,-soname,libfoo.so.1 -o libfoo.so ...


See our DeBugging page for more details.