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").
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).
Other neat tools for diagnosing memory errors are:
5 pages link to CommonProgrammingBugs: