4

I'm experiencing some problems with my C program on Linux. It compiles and runs just fine on Windows. The Linux terminal returns this information:

*** stack smashing detected ***: ./student terminated       
======= Backtrace: =========                                
/lib/libc.so.6(__fortify_fail+0x4b)[0xb7e908ab]             
/lib/libc.so.6(__fortify_fail+0x0)[0xb7e90860]              
./student[0x8048c09]                                        
./student[0x80486dd]                                        
/lib/libc.so.6(__libc_start_main+0xe5)[0xb7dc0775]
./student[0x80485e1]
======= Memory map: ========
08048000-0804a000 r-xp 00000000 00:11 11222      /mnt/win/POT03/Eclipse/student
0804a000-0804b000 r--p 00001000 00:11 11222      /mnt/win/POT03/Eclipse/student
0804b000-0804c000 rw-p 00002000 00:11 11222      /mnt/win/POT03/Eclipse/student
0804c000-0821a000 rw-p 0804c000 00:00 0          [heap]
b7da9000-b7daa000 rw-p b7da9000 00:00 0
b7daa000-b7eeb000 r-xp 00000000 75:00 116292     /lib/libc-2.9.so
b7eeb000-b7eed000 r--p 00141000 75:00 116292     /lib/libc-2.9.so
b7eed000-b7eee000 rw-p 00143000 75:00 116292     /lib/libc-2.9.so
b7eee000-b7ef1000 rw-p b7eee000 00:00 0
b7ef4000-b7f01000 r-xp 00000000 75:00 116275     /lib/libgcc_s.so.1
b7f01000-b7f02000 r--p 0000c000 75:00 116275     /lib/libgcc_s.so.1
b7f02000-b7f03000 rw-p 0000d000 75:00 116275     /lib/libgcc_s.so.1
b7f03000-b7f06000 rw-p b7f03000 00:00 0
b7f06000-b7f22000 r-xp 00000000 75:00 116288     /lib/ld-2.9.so
b7f22000-b7f23000 r--p 0001b000 75:00 116288     /lib/ld-2.9.so
b7f23000-b7f24000 rw-p 0001c000 75:00 116288     /lib/ld-2.9.so
bf8eb000-bf900000 rw-p bf8eb000 00:00 0          [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]
Aborted

What can I do with this information to trace the problem?

Pieter
  • 31,619
  • 76
  • 167
  • 242

2 Answers2

7

Compile your program with debug info then run with valgrind.

gcc -g student.cpp -o student
valgrind ./student

To try a debugger:

gcc -g student.cpp -o student
gdb ./student
run
     // wait for it to crash
backtrace
help // to figure out what else you can do
  • 4
    +1 for valgrind -- it will probably be much more useful than gdb here. – Chris Dodd Feb 21 '10 at 20:09
  • 1
    The main problem (I think) with using GDB `bt` is, that the smashed stack will only be noticed at return (end of a block/function).So the line you see in the backtrace output will be the closing brace and somewhere inside you write over a stack allocated buffer/array. – eckes Apr 25 '13 at 22:26
  • The advice here is not likely to be all that helpful to others in this situation. First, Valgrind is not likely to help you spot the problem, since the problem is a stack smashing overflow -- Valgrind is not very effective at dealing with stack-allocated buffers. Second, a debugger is going to give you a stack trace at the point where you returned from the function where the buffer was allocated, not a stack trace at the point where you wrote past the end of the buffer. Turning off stack-protector is a terrible idea; if you're getting this message, you have a serious security vulnerability. – D.W. Feb 09 '14 at 02:20
1

Firstly you need a map file. From the map file you can look up the memory address (0x8048c09). The function will actually start at an address prior to the address in the stack. From here you know which function you are crashed in and with a bit of knowledge of the assembler generated you can figure out how far into the function it crashed. You then look at the code and try to figure out what you are doing wrong.

Failing that ... use a debugger. You'll then be able to see whereabouts it crashed. From there you may even be able (if you are running an optimised build you WILL be able) to see what exactly you are calling and what the parameters are. You can then see what is causing the problem and you can stop it from occurring.

Goz
  • 61,365
  • 24
  • 124
  • 204
  • Yuck, assembler... the relatively small size of the program is not worth that effort. I'll try to find out where the program crashed using the debugger instead. – Pieter Feb 21 '10 at 20:07