tags:

views:

57

answers:

2

Hi

I have a widows crash-dump with a call stack showing me the module!functionname+offset of the function that caused the crash. The module is built without debug information using gcc.

The cause of the crash is an exception caused by a failed to write at a given address, i.e access violation(05), write violation(01)

On my development machine I have access to the same module built with debugging information. What I'm looking for is a way to track down the corresponding source code line that caused the crash, this by using the module!functionname+offset information as starting point.

The method name of the top frame in the call stack is a class destructor The mangled function name is _ZN20ViewErrorDescriptionD0Ev+x79

Running objdump -d searching for the module!functionname+offset gives:

.... call *%eax 
.... mov 0xffffffbc(%ebp), %eax
.... cmpl 0x0, 0x148(%eax)

trying to find this in the debug built file gives no match

The source code of the destructor only contains two delete pointerX calls.

Using gdb to load the debug built module(sharedlibrary) and then calling info line gives me a starting and ending address, using grep on the objdump output shows the corresponding disassembled code, which looks quite much like the one from the module without debug info, but still far from the same.

!NB - The output from info line says _ZN20ViewErrorDescriptionD2Ev not _ZN20ViewErrorDescriptionD0Ev as the crash dump says.

Taken from the ABI documentation: ::= D1 # complete object destructor ::= D2 # base object destructor

Where do I go from here?

Best regards Kristofer H

A: 

This works on the assumption that gcc compilation is 100% deterministic. I'm not sure how valid that assumption is. However, taking the further assumption that you still have exactly the same source code you could try enabling the gcc's -S command line option and rebuilding. This will result in a set of .s files, one for each source file, containing the assembly code. You can then search through this for the code machine code that you want to find.

torak
A: 

Unfortunately even debug/non-debug builds may have different address layouts. The only way I'm aware of to accomplish something like this is to build with debug symbols and save off a copy of that binary. Then you can deploy a stripped version without the debug information.

Your approach attempting to locate the assembly code seems the most hopeful here. I would expand that even though: Try to look at a much larger chunk of assembly in the crashed file and see if you can generate more context yourself rather than having the computer attempt to match low-level instructions that might in fact slightly differ.

Mark B