Segmentation faults in memory allocation and free routines invariably mean that you've done something bad (like buffer overrun) somewhere else in your program.
Unfortunately, cause (what went wrong) and effect (the segfault) are seldom related. Looking at the effect is seldom instructive at working out the problem.
There are numerous memory debuggers aimed at finding where the problem is.
An example program with a deliberate array overstep
Code:
#include <iostream>
int main() {
int *mem = new int[10];
for ( int i = 0 ; i <= 10 ; i++ ) mem[i] = 0;
delete [] mem;
return 0;
}
We compile this with debug information, and use a memory debugger - in this case, Electric Fence.
[tt]g++ -ggdb hello.cpp -lefence[/tt]
Running in the debugger gets us this
[tt]gdb a.out
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run
Starting program: a.out
[New Thread 8192 (LWP 13040)]
Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 13040)]
0x08048698 in main () at hello.cpp:4
4 for ( int i = 0 ; i <= 10 ; i++ ) mem
= 0;
(gdb) print i
$1 = 10
(gdb) quit
[/tt]
Electric fence arranges things so that segfaults occur at the point of overrun, which the debugger catches. It then displays for us the offending line of code 
Examining variables shows that the subscript was off by one on the last iteration of the loop.
--