What to do with error information after stack smashing

Question

I am having some problems with my Linux program. It compiles and works 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 track the problem?

Answer 1

Compile your program with debugging information, then run with valgrind.

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

Try the 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 

Answer 2

First, you need a map file. From the map file you can find the memory address (0x8048c09). The function will actually start from address to address on the stack. From here you know what function you came across, and with a little knowledge of the assembler you can understand how far it crashed. Then you look at the code and try to figure out what you are doing wrong.

Otherwise ... use a debugger. Then you can see where it crashed. From there, you can even (if you use an optimized assembly that you can) to find out exactly what you are calling and what are the parameters. Then you can see what causes the problem, and you can stop it.