我怎样才能解释.stackdump文件？

Question

this question is likely a repeat of Using a stackdump from Cygwin executable - but I'm a beginner, and I didn't understand the answers, or even parts of the question.

I'm pretty new to c++ and programming and I'm developing in NetBeans. I'm working on some code that compiles just fine, but fails while running. If I use the debugger I get the following error:

1 [main] all 6200 exception::handle: Exception: STATUS_ACCESS_VIOLATION
881 [main] all 6200 open_stackdumpfile: Dumping stack trace to all.exe.stackdump

I've managed to find the file all.exe.stackdump, and I can read it via notepad++, but I don't understand what it means. I gather by the other question that there's a user friendly way to decode this file, but my best guess bash$ gdb all.exe.stackdump was ineffective. What's the best way for me to use this file in debugging?

Just in case it's helpful, here's the contents of all.exe.stackdump

Exception: STATUS_ACCESS_VIOLATION at eip=00434C41
eax=2003A2E4 ebx=0028A95C ecx=00000000 edx=0028A95C esi=0028A9B0 edi=00000000
ebp=0028A9C8 esp=0028A930 program=[redacted for privacy/security], pid 6200, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
0028A9C8  00434C41  (00000000, 2003A4F0, 0028A9E8, 00000000)
0028A9E8  00436B14  (00000000, 2003A4F0, 0028AA28, 0028D000)
0028AAF8  004036A4  (0028AB80, 2003A2B0, 00000014, 00000003)
0028ABD8  00403FBC  (00000001, 0028AC00, 200280E8, 2003A189)
0028ACF8  61007535  (00000000, 0028CD78, 61006B20, 00000000)
End of stack trace

Answer 1

You can use the "Function" addresses as arguments to addr2line .

addr2line -f -C -e main.exe 0xADD4355

Filter it using awk and pipe in all addresses:

awk '/^[0-9]/{print $2}' main.exe.stackdump | addr2line -f -C -e main.exe

If you see ?? 's instead of function names, you'll need to rebuild with debug symbols ( -g , -ggdb3 , ... )

Answer 2

This is a common problem for many guys; and usually they will tell you use gdb. However this is not always a reasonable answer. You mustn't re-compile it, since it isn't guaranteed the new build has same symbol addresses as the crashed one. There are several tools that could be helpful: objdump, addr2line, etc. You can do "objdump -D -S build.out > build.rasm.txt", and then search those functions addresses among the text. Addr2line is also a good choice for identify those functions. If you are going to handle such crash problems often, it's suggested writing a script tool to help your work.

Good luck.

Answer 3

Another way to find the problematic line would be to use gdb on your binary file. So run gdb first: gdb main.exe

Inside gdb run: info line *0xADD4355