I program I'm writing crashes when it exits with a segfault. I'm runnning under linux. Using gdb, i see that the crash happens after the last line of main(), which is just a return(EXIT_SUCCESS); If I put an exit(EXIT_SUCCESS); right before that line, it doesn't crash though!
In gdb, when the crash occurs, a backtrace gives the following:
#0 0x0804e090 in ?? ()
#1 0xb7ea2ff4 in ?? () from /usr/lib/debug/libc.so.6
#2 0xb7ea4140 in ?? () from /usr/lib/debug/libc.so.6
#3 0x0804e008 in ?? ()
#4 0xbfac1928 in ?? ()
#5 0xb7ddade9 in *__GI___libc_free (mem=0x0) at malloc.c:3622
#6 0x08048c51 in _start ()
I'm using a debug version of libc, as you can see, but it doesn't help much.
http://c-faq.com/strangeprob/crashatexit.html describes the problem, but the solutions don't seem to apply to my program.
The really strange thing is that the problem is erratic - usually it happens the way but occasionally (maybe every 10th time or so) there's no problem at all, or else it just freezes without a segfault. When frozen, I've attached gdb, and it reports that it's just sitting on the last line of the program - just the final curly bracket - over and over again with nothing changing.
Valgrind shows the following when it crashes:
==24604== Use of uninitialised value of size 4
==24604== at 0x8049AAB: main (ttuner.c:234)
==24604==
==24604== Invalid read of size 1
==24604== at 0x41E5FF6: (within /usr/lib/debug/libc-2.6.1.so)
==24604== by 0x8048C50: (within /home/jono/src/ttuner/ttuner)
==24604== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==24604==
==24604== Process terminating with default action of signal 11 (SIGSEGV)
==24604== Access not within mapped region at address 0x0
==24604== at 0x41E5FF6: (within /usr/lib/debug/libc-2.6.1.so)
==24604== by 0x8048C50: (within /home/jono/src/ttuner/ttuner)
==24604==
==24604== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 19 from 1)
==24604== malloc/free: in use at exit: 0 bytes in 0 blocks.
==24604== malloc/free: 10 allocs, 10 frees, 1,381,121 bytes allocated.
==24604== For counts of detected errors, rerun with: -v
==24604== All heap blocks were freed -- no leaks are possible.
Is there anything else that might be helpful in debugging this?