Question

As part of my JOB, often I have to analyse un-reproducible retail crashes with/ without a core dump. I am generally equipped with

  1. Call Stack, registry information at the time of crash, singal information
  2. Actual Load Modules
  3. Matching Source Code

Generally, based on the offset and generating the dis-assembly via objdump, I calculate the failing instruction (machine code/assembly code).

The next JOB is tedious. I try to map the failing instruction to the actual source location. This is time consuming and painful. Is there a painless, easy way to map the source code to the failing instruction?

I tried using the assembly source using the gcc -S option, but cannot effectively map the source. I generally cannot find a logical way to map the assembly output with the crashing offset with the source.

Please suggest the recommended approach.

Was it helpful?

Solution

Create your retail code with debugging information enabled, then strip it before shipping but keep it for yourself. Then you can use your copy for analyzing core dumps.

OTHER TIPS

Key here is to have a precise version system (including version control software to store the source code) so that you can have a definitive matching pair of binary and source code. This should include EXACTLY what version of compiler, and what compiler options and all of the header and library code used to build the final binary.

Now, if you have this, you can recreate an identical build to what the customer is running, but WITH debug information, and use that in gdb to debug the code.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top