How to detect the point of a stack overflow

Manuel picture Manuel · Apr 12, 2009 · Viewed 8.5k times · Source

I have the following problem with my C program: Somewhere is a stack overflow. Despite compiling without optimization and with debugger symbols, the program exits with this output (within or outside of gdb on Linux):

Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists.

The only way I could detect that this actually is stack overflow was running the program through valgrind. Is there any way I can somehow force the operating system to dump a call stack trace which would help me locate the problem?

Sadly, gdb does not allow me to easily tap into the program either.

Answer

David Rodríguez - dribeas picture David Rodríguez - dribeas · Apr 12, 2009

If you allow the system to dump core files you can analyze them with gdb:

$ ulimit -c unlimited # bash sentence to allow for infinite sized cores
$ ./stack_overflow
Segmentation fault (core dumped)
$ gdb -c core stack_overflow
gdb> bt
#0  0x0000000000400570 in f ()
#1  0x0000000000400570 in f ()
#2  0x0000000000400570 in f ()
...

Some times I have seen a badly generated core file that had an incorrect stack trace, but in most cases the bt will yield a bunch of recursive calls to the same method.

The core file might have a different name that could include the process id, it depends on the default configuration of the kernel in your current system, but can be controlled with (run as root or with sudo):

$ sysctl kernel.core_uses_pid=1