It's common for a program to cause a SegmentationFault 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 using -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 (this is the default on most recent distros, use ulimit -c unlimited to allow 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 lots of chatter... (gdb) bt full
If it says (no symbols) then you didn't compile with -g above. bt full will take the backtrace 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(3)d).
See DeBugging for more details.
You are linking against a shared library that was created incorrectly. With GCC 3.x this might happen if you create a SharedLibrary directly using ld -shared -o libfoo.so .... Instead, use g++ -shared -Wl,-soname,libfoo.so.1 -o libfoo.so ...
5 pages link to CommonProgrammingBugs:
