Updated: 11 December 1998 |
OpenVMS Alpha System Analysis Tools Manual
Previous | Contents | Index |
This chapter describes the OpenVMS Alpha System Dump Debugger and how it can be used to analyze system crash dumps.
The system dump debugger is similar in concept to the system code debugger described in Chapter 7. Where the system code debugger allows connection to a running system, with control of the system's execution and the examination and modification of variables, the system dump debugger allows analysis of memory as recorded in a system dump.
Use of the system dump debugger usually involves two systems, although all the required environment can be set up on a single system. The description that follows assumes that two systems are being used:
In common with the system code debugger, the OpenVMS debugger's user interface allows you to specify variable names, routine names, and so on, precisely as they appear in your source code. Also, the system dump debugger can display the source code where the software was executing at the time of the system crash.
The system dump debugger recognizes the syntax, data typing, operators, expressions, scoping rules, and other constructs of a given language. If your code or driver is written in more than one language, you can change the debugging context from one language to another during a debugging session.
To use the system dump debugger, you must do the following:
The following sections cover these tasks in more detail, describe the
available user-interface options, summarize applicable OpenVMS Debugger
commands, and provide a sample system dump debugger session.
8.1 User-Interface Options
The system dump debugger has the following user-interface options.
To prepare a system dump for analysis, perform the following steps:
Because you are analyzing a snapshot of the system, it is not as vital to use unoptimized code as it is with the system code debugger. But note that you cannot access all variables. The system dump debugger may report that they are optimized away. |
$ LINK/EXE=EXE$:MY_EXECLET/DSF=EXE$:MY_EXECLET OPTIONS_FILE/OPT |
The only requirement for the test system is that the .DSF file matching the .EXE file that causes the crash is available on the build system.
There are no other steps necessary in the setup of the test system. With the system image copied to the test system, it can be booted in any way necessary to produce the system crash. Since the system dump debugger can analyze most system crash dumps, any system can be used, from a standalone system to a member of a production cluster.
It is assumed that the test system has a dump file large enough for the system dump to be recorded. Any dump style may be used (full or selective, compressed or uncompressed). A properly AUTOGENed system will meet these requirements. |
To set up the build system, you need access to all system images and drivers that were loaded on the test system. You should have access to a source listings kit or a copy of the following directories:
SYS$LOADABLE_IMAGES: SYS$LIBRARY: SYS$MESSAGE: |
You need all the .EXE files in those directories. The .DSF files are available with the OpenVMS Alpha source listings kit.
Optionally, you need access to the source files for the images to be debugged. The system dump debugger will look for the source files in the directory where they were compiled. You must use the SET SOURCE command to point the system dump debugger to the location of the source code files if they are not in the directories used when the image was built. For an example of the SET SOURCE command, see Section 8.9.
Before you can analyze a system dump with the system dump debugger, you must set up the logical name DBGHK$IMAGE_PATH, which must be set up as a search list to the area where the system images or .DSF files are kept. For example, if the copies are in the following directories,
DEVICE:[SYS$LDR] DEVICE:[SYSLIB] DEVICE:[SYSMSG] |
you would define DBGHK$IMAGE_PATH as follows:
$ define dbghk$image_path DEVICE:[SYS$LDR],DEVICE:[SYSLIB],DEVICE:[SYSMSG] |
This works well for analyzing a system dump using all the images normally loaded on a given system. However, you might be using the system dump debugger to analyze new code in an execlet or a new driver. Because that image is most likely in your default directory, you must define the logical name as follows:
$ define dbghk$image_path [],DEVICE:[SYS$LDR],DEVICE:[SYSLIB],DEVICE:[SYSMSG] |
If the system dump debugger cannot find one of the images through this search path, a warning message is displayed. The system dump debugger will continue initialization as long as it finds at least one image. If the system dump debugger cannot find the SYS$BASE_IMAGE file, which is the OpenVMS Alpha operating system's main image file, an error message is displayed and the debugger exits.
If and when this happens, check the directory for the image files and
compare it to what was loaded on the test system.
8.5 Starting the System Dump Debugger
To start the system dump debugger on the build system, enter the following command.
$ DEBUG/KEEP |
The system dump debugger displays the DBG> prompt. With the DBGHK$IMAGE_PATH logical name defined, you can invoke the ANALYZE/CRASH_DUMP command and optional qualifier /IMAGE_PATH.
To use the ANALYZE/CRASH_DUMP command and optional qualifier (/IMAGE_PATH) to analyze the dump in file <file-name> enter the following command:
DBG> ANALYZE/CRASH_DUMP file-name |
The /IMAGE_PATH qualifier is optional. If you do not use this qualifier, the system dump debugger uses the DBGHK$IMAGE_PATH logical name as the default. The /IMAGE_PATH qualifier is a quick way to change the logical name. However, when you use it, you cannot specify a search list. You can use only a logical name or a device and directory, although the logical name can be a search list.
Usually, the system dump debugger gets the source file name from the
object file. This is put there by the compiler when the source is
compiled with the /DEBUG qualifier. The SET SOURCE command can take a
list of paths as a parameter. It treats them as a search list.
8.6 Summary of System Dump Debugger Commands
Only a subset of OpenVMS debugger commands can be used in the system dump debugger. The following are a few examples of commands that can be used in the system dump debugger.
Examples of commands that cannot be used in the system dump debugger are as follows:
In addition, the OpenVMS debugger command SDA can be used to examine
the system dump with System Dump Analyzer semantics. This command,
which is not available when debugging user programs, is described in
the next section.
8.7 Using System Dump Analyzer Commands
Once a dump file has been opened, the commands listed in the previous section can be used to examine the system dump. In addition, some System Dump Analyzer (SDA) commands, such as SHOW SUMMARY and SHOW DEVICE, can be used. This feature allows the system programmer to take advantage of the strengths of both the OpenVMS Debugger and SDA to examine the system dump and to debug system programs such as device drivers, without having to invoke both the OpenVMS debugger and SDA separately.
To obtain access to SDA commands, you simply type "SDA" at the OpenVMS Debugger prompt ("DBG>") at any time after the dump file has been opened. SDA initializes itself and then outputs the "SDA>" prompt. Enter SDA commands as required. (See Chapter 4 for more information.) To return to the OpenVMS Debugger, you enter "EXIT" at the "SDA>" prompt. Optionally, you may invoke SDA to perform a single command and then return immediately to the OpenVMS Debugger, as in the following example:
DBG> SDA SHOW SUMMARY |
SDA may be reentered at any time, with or without the optional SDA command. Once SDA has been initialized, the SDA> prompt is output more quickly on subsequent occasions.
Note that there are some limitations on the use of SDA from within the System Dump Debugger as with the following:
If the need arises to switch between processes or CPUs in the system
dump, then SDA must be invoked separately using the DCL command
ANALYZE/CRASH_DUMP.
8.8 Limitations of the System Dump Debugger
The system dump debugger provides a narrow window into the context of the system that was current at the time that the system crashed (stack, process, CPU, etc.). It does not provide full access to every part of the system as is provided by the system dump analyzer. However, it does provide a view of the failed system using the semantics of the OpenVMS debugger---source correlation and display, call frame traversal, examination of variables by name, language constructs, etc.
The system dump debugger therefore provides an additional approach to
analyzing system dumps that is difficult to realize with SDA, often
allowing quicker resolution of system crashes than is possible with SDA
alone. When the system dump debugger cannot provide the needed data
from the system dump, SDA should be used instead.
8.9 Access to Symbols in OpenVMS Executive Images
For a discussion and explanation of how the OpenVMS debugger accesses
symbols in OpenVMS executive images, see Section 7.11 in Chapter 7.
8.10 Sample System Dump Debugging Session
This section provides a sample session that shows the use of some OpenVMS debugger commands as they apply to the system dump debugger. The examples in this section show how to work with a dump created as follows:
DBG> DEPOSIT R27=0 DBG> GO |
$ analyze/crash sys$system:sysdump.dmp |
OpenVMS (TM) Alpha system dump analyzer ...analyzing a selective memory dump... %SDA-W-NOTSAVED, global pages not saved in the dump file Dump taken on 1-JAN-1998 00:00:00.00 INVEXCEPTN, Exception while above ASTDEL SDA> copy hstsys::sysdump.dmp SDA> |
To reproduce this sample session, you need access to the SYSTEM_DEBUG.DSF matching the SYSTEM_DEBUG.EXE file on your test system and to the source file C_TEST_ROUTINES.C, which is available in SYS$EXAMPLES.
The example begins by invoking the system dump debugger's character cell interface on the build system.
Example 8-1 Invoking the System Dump Debugger |
---|
$ define dbg$decw$display " " $ debug/keep OpenVMS Alpha Debug64 Version V7.2-019 DBG> |
Use the ANALYZE/CRASH_DUMP command to open the system dump. In this example, the logical name DBGHK$IMAGE_PATH is used for the image path; so the command qualifier /IMAGE_PATH is not being used. You may need to use it.
When you have opened the dump file, the DEBUG prompt is displayed. You should now do the following:
Example 8-2 Accessing the System Dump |
---|
DBG> analyze/crash_dump sysdump.dmp %SDA-W-NOTSAVED, global pages not saved in the dump file %DEBUG-I-INIBRK, target system interrupted %DEBUG-I-DYNIMGSET, setting image SYSTEM_DEBUG %DEBUG-I-DYNMODSET, setting module C_TEST_ROUTINES DBG> set source/latest sys$examples,sys$library DBG> set language c DBG> |
Now that the debugger has access to the source, you can put the debugger into screen mode to see exactly where you are and the code surrounding it.
Example 8-3 Displaying the Source Code |
---|
DBG> Set Mode Screen; Set Step Nosource - SRC: module C_TEST_ROUTINES -scroll-source------------------------------------ 135: int i,k; 136: for(k=0;k<1000;k++) 137: { 138: test_c_code5(&i); 139: } 140: return; 141: } 142: int test_c_code3(int subrtnCount) 143: { 144: subrtnCount = subrtnCount - 1; 145: if (subrtnCount != 0) -> 146: subrtnCount = test_c_code3(subrtnCount); 147: return subrtnCount; 148: } 149: int test_c_code2(int64 in64,int in32, int64 test, int64* pVar) 150: { 151: xdt$fregsav[5] = in64; 152: xdt$fregsav[6] = in32; 153: if (xdt$fregsav[9] > 0) 154: *pVar = (*pVar + xdt$fregsav[17])%xdt$fregsav[9]; 155: else 156: *pVar = (*pVar + xdt$fregsav[17]); 157: xdt$fregsav[7] = test_c_code3(10); - OUT -output------------------------------------------------------------------- - PROMPT -error-program-prompt-------------------------------------------------- DBG> |
Now, you try a couple of other commands, EXAMINE and SHOW CALLS. The EXAMINE command allows you to look at all the C variables. Note that the C_TEST_ROUTINES module is compiled with the /NOOPTIMIZE switch which allows access to all variables. The SHOW CALLS command shows you the call sequence from the beginning of the stack. In this case, you started out in the image EXEC_INIT. (The debugger prefixes all images other than the main image with SHARE$ so it shows up as SHARE$EXEC_INIT.)
Example 8-4 Using the Examine and Show Calls Commands |
---|
DBG> Set Mode Screen; Set Step Nosource - SRC: module C_TEST_ROUTINES -scroll-source------------------------------------ 135: int i,k; 136: for(k=0;k<1000;k++) 137: { 138: test_c_code5(&i); 139: } 140: return; 141: } 142: int test_c_code3(int subrtnCount) 143: { 144: subrtnCount = subrtnCount - 1; 145: if (subrtnCount != 0) -> 146: subrtnCount = test_c_code3(subrtnCount); 147: return subrtnCount; 148: } 149: int test_c_code2(int64 in64,int in32, int64 test, int64* pVar) 150: { 151: xdt$fregsav[5] = in64; 152: xdt$fregsav[6] = in32; 153: if (xdt$fregsav[9] > 0) 154: *pVar = (*pVar + xdt$fregsav[17])%xdt$fregsav[9]; 155: else 156: *pVar = (*pVar + xdt$fregsav[17]); 157: xdt$fregsav[7] = test_c_code3(10); - OUT -output------------------------------------------------------------------- C_TEST_ROUTINES\test_c_code3\subrtnCount: 9 module name routine name line rel PC abs PC *C_TEST_ROUTINES test_c_code3 146 00000000000000CC FFFFFFFF83002D6C *C_TEST_ROUTINES test_c_code2 157 00000000000001A0 FFFFFFFF83002E40 *C_TEST_ROUTINES test_c_code 170 0000000000000260 FFFFFFFF83002F00 *XDELTA XDT$SYSDBG_INIT 9371 0000000000000058 FFFFFFFF83052238 *SYS$DOINIT INI$DOINIT 1488 0000000000000098 FFFFFFFF830520B8 SHARE$EXEC_INIT 0000000000018C74 FFFFFFFF83086C74 SHARE$EXEC_INIT 0000000000014BD0 FFFFFFFF83082BD0 - PROMPT -error-program-prompt-------------------------------------------------- DBG> e subrtnCount DBG> show calls DBG> |
Previous | Next | Contents | Index |
Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal |
6549PRO_029.HTML
|