[LCP]debugging a SIGSEGV

[Jack Lloyd]

I've seen this happen (SIGSEGV after main returns) a few times. It's been a
while, but ISTR that in the end I always found I was trashing some internal
memory structure. For example, if you trash something in the stack of the libc
startup code (called __libc_start_main in glibc, I think), you'll get a crash
after main returns and __libc_start_main resumes.

In C++ this can also happen if a destructor for a global object does something
stupid; looking at the stack trace at the time of failure will probaby diagnose
this (you'll see in the call chain a GCC generated function for destroying
global objects).

A tool that may help tracking this down is Valgrind. If nothing else, a clean
Valgrind run will eliminate the possibility that it's a memory error.

-Jack

On Sun, Feb 06, 2005 at 02:32:48PM -0500, Karthik Vishwanath wrote:
> My program quits _after_ processing the last lines of main() with a
> SIGSEGV (the last lines of main() are a printf() statements). I compiled
> the program using the -ggdb flags and used ddd to execute the program to
> get any more info. on where the code dies and heres what ddd tells me:
> "Program received signal SIGSEGV, Segmentation fault. 0x4012be5b in
> __register_atfork () from /lib/libc.so.6 (gdb) "
> 
> Can anyone tell me what is going on, and why this could be happening (I
> have checked writes to malloc'd *s very carefully and I don't think its
> because of accessing an uninitialized memory location etc.)?  Any/all
> pointers (no pun intended) toward throwing some light on how to get rid of
> the segmentation fault will be very appreciated.
> 
> Thanks,
> 
> -K
> 
> 
> 
> _______________________________________________
> This is the Linux C Programming List
> :  http://lists.linux.org.au/listinfo/linuxcprogramming List