views:

120

answers:

2

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?

+1  A: 

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
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
+5  A: 

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
Also, a quick hack to (probably) make it run is to add -fno-stack-protector when you compile. But you should really find the bug.
+1 for valgrind -- it will probably be much more useful than gdb here.
Chris Dodd
+1 for valgrind and +1 for Chris for +1 for Valgrind :)
Tim Post