9.9 Generate memory dump


9.9 Generate memory dump

9.9.1 Basic tactic

Generate a memory map when the application is compiled and a memory dump when it completes execution.

9.9.2 Purpose

Determine the state of all program variables.

9.9.3 Questions answered

  • What were the values of all active variables when the program stopped?

9.9.4 Potential problems

  • Memory dumps of virtual memory programs can use hundreds of megabytes of file storage.

  • Identifying patterns in large dumps requires good tools or lots of time.

9.9.5 Refined tactics

  1. Run the binary dump values through a program that has access to all the header files and dumps values in their natural container size and format.

  2. Run the binary dump through a tool that extracts only certain ranges of addresses.

9.9.6 Related tactics

  • Insert an event handler in the main procedure that will catch all unhandled events.

  • Use a high-level debugger or interpreter to do the following:

    • Set a breakpoint at the entry to the event handler.

    • Add a command list to the breakpoint that prints a stack trace if the breakpoint is taken.

  • If the application terminated abnormally, some operating systems will automatically produce an image of the executable when it quit. On UNIX systems, these are called core files. This is because they replicate the memory image of the program, and back in the bad old days when UNIX was invented, computers still used ferrite core rings to represent bits of information in memory. On Windows systems, these files are called Dr. Watson log files. Dr. Watson was Sherlock Holmes’s assistant.

Regardless of the platform, these logs can be used to identify the source of a problem in a postmortem fashion. You must run a tool, either the normal interactive debugger or a special tool (the Dr. Watson program), which will generate the following information for you:

  • Stack trace at the time the program stopped

  • Event/exception/fault that caused the failure

  • Assembly instruction that failed

  • If the source code is available, the high-level language statement that failed

  • Contents of hardware registers

  • System status and other miscellaneous information

On some systems, you may have to start a monitoring program, or change the properties of the executable to have these log files generated for you.

9.9.7 Choosing tactics

Use basic or refined tactics when dealing with a program that must reside in memory for long periods of time. Two types of programs that have this characteristic are operating system kernels and database managers.

Use related tactic 2 when you don’t have access to the system on which the failure occurred and the user is unable to provide enough useful information on how the program failed for you to diagnose the problem. Instruct the user to do what is necessary to cause a log file to be generated and send the log file to you.




Debugging by Thinking. A Multidisciplinary Approach
Debugging by Thinking: A Multidisciplinary Approach (HP Technologies)
ISBN: 1555583075
EAN: 2147483647
Year: 2002
Pages: 172

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net