Comments on: Is your stacktrace really corrupted? http://www.iovene.com/34 The thoughts of a computer programmer, open source supporter and free-thinker. Mon, 19 Jul 2010 23:38:11 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Eldar http://www.iovene.com/34#comment-105938 Eldar Tue, 01 Jun 2010 12:17:49 +0000 http://www.iovene.com/is-your-stacktrace-really-corrupted/#comment-105938 Cool article. You real help me :) Thank you. Cool article. You real help me :)
Thank you.

]]> By: Ivers http://www.iovene.com/34#comment-36017 Ivers Thu, 25 Sep 2008 10:59:26 +0000 http://www.iovene.com/is-your-stacktrace-really-corrupted/#comment-36017 Real cool article... thank you. I used your tips and found an improvement: You can actually achieve this very fast by: print the current stack frame: x/20wx $esp print the previous stack frame: x/20wx *(int *)$ebp print the preprevious stack frame: x/20wx **(int **)$ebp cool, eh? Addressing with registers turns out to be REALLY helpful. I'm debugging a program without debug-symbols :-(.. and found e.g.: display *(char *)($esp+4) to work real great! Real cool article… thank you.

I used your tips and found an improvement:

You can actually achieve this very fast by:

print the current stack frame:
x/20wx $esp

print the previous stack frame:
x/20wx *(int *)$ebp

print the preprevious stack frame:
x/20wx **(int **)$ebp

cool, eh?

Addressing with registers turns out to be REALLY helpful. I’m debugging a program without debug-symbols :-( .. and found e.g.:

display *(char *)($esp+4)

to work real great!

]]> By: How to debug a corrupted stack « Interview questions http://www.iovene.com/34#comment-32469 How to debug a corrupted stack « Interview questions Sun, 14 Sep 2008 17:01:22 +0000 http://www.iovene.com/is-your-stacktrace-really-corrupted/#comment-32469 [...] to debug a corrupted stack Is your stacktrace really corrupted? by Salvatore Iovene on 17 October 2006 — Posted [...] […] to debug a corrupted stack Is your stacktrace really corrupted? by Salvatore Iovene on 17 October 2006 — Posted […]

]]> By: Salvatore Iovene http://www.iovene.com/34#comment-45 Salvatore Iovene Mon, 05 Feb 2007 22:23:58 +0000 http://www.iovene.com/is-your-stacktrace-really-corrupted/#comment-45 Very interesting contribution, thank you! Very interesting contribution, thank you!

]]> By: Ionut Georgescu http://www.iovene.com/34#comment-43 Ionut Georgescu Mon, 05 Feb 2007 21:17:04 +0000 http://www.iovene.com/is-your-stacktrace-really-corrupted/#comment-43 I am not a GDB specialist, but I do not understand why GDB cannot trace back %esp if we can do it ... However, great description of how one can shoot himself in the foot by overwriting the stack. One can also find the symbols directly from within gdb info symbol Of course, it is only reliable as long as we can trust gdb. On the other hand, it is the only way to get the symbol information if the bug is in some shared library, because objdump cannot tell at which address the library was or will be loaded. This address is a random number generated by the dynamic linker (ld-linux.so) when the program is loaded into memory. In my case nothing worked, as the stack was heavily trashed by somebody :-) (gdb) info registers esp esp 0xaf970d94 0xaf970d94 (gdb) x/20xw 0xaf970d94 0xaf970d94: 0xaf970dac 0x00000006 0x00000e16 0xa7ae8811 0xaf970da4: 0xa7becff4 0xa7aada40 0xaf970ed8 0xa7ae9fb9 0xaf970db4: 0x00000006 0xaf970e4c 0x00000000 0x0000000d 0xaf970dc4: 0x00000023 0x0000002f 0x00000027 0x0000002d 0xaf970dd4: 0x00000022 0x00000016 0x00000036 0x0000002b (gdb) info symbol 0xaf970dac No symbol matches 0xaf970dac. (gdb) disassemble 0xaf970dac No function contains specified address. (gdb) I am not a GDB specialist, but I do not understand why GDB cannot trace back %esp if we can do it …

However, great description of how one can shoot himself in the foot by overwriting the stack.

One can also find the symbols directly from within gdb

info symbol

Of course, it is only reliable as long as we can trust gdb. On the other hand, it is the only way to get the symbol information if the bug is in some shared library, because objdump cannot tell at which address the library was or will be loaded. This address is a random number generated by the dynamic linker (ld-linux.so) when the program is loaded into memory.

In my case nothing worked, as the stack was heavily trashed by somebody :-)

(gdb) info registers esp
esp 0xaf970d94 0xaf970d94
(gdb) x/20xw 0xaf970d94
0xaf970d94: 0xaf970dac 0x00000006 0x00000e16 0xa7ae8811
0xaf970da4: 0xa7becff4 0xa7aada40 0xaf970ed8 0xa7ae9fb9
0xaf970db4: 0x00000006 0xaf970e4c 0x00000000 0x0000000d
0xaf970dc4: 0x00000023 0x0000002f 0x00000027 0x0000002d
0xaf970dd4: 0x00000022 0x00000016 0x00000036 0x0000002b
(gdb) info symbol 0xaf970dac
No symbol matches 0xaf970dac.
(gdb) disassemble 0xaf970dac
No function contains specified address.
(gdb)

]]>