Tutorial :How to detect the point of a stack overflow



Question:

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.


Solution:1

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  


Solution:2

With GCC you can try this:

-fstack-protector
Emit extra code to check for buffer overflows, such as stack smashing attacks. This is done by adding a guard variable to functions with vulnerable objects. This includes functions that call alloca, and functions with buffers larger than 8 bytes. The guards are initialized when a function is entered and then checked when the function exits. If a guard check fails, an error message is printed and the program exits.

-fstack-protector-all
Like -fstack-protector except that all functions are protected.

http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#Optimize-Options


Solution:3

When a program dies with SIGSEGV, it normally dumps core on Unix. Could you load that core into debugger and check the state of the stack?


Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »