Previous | Contents | Index |
Invokes the OpenVMS Debugger to analyze a process dump file that was created when an image failed during execution. (Use the /DUMP qualifier with the RUN or the SET PROCESS command to generate a dump file.)Note that on Alpha systems, you can also force a process to dump by using the DUMP/PROCESS command.
The ANALYZE/PROCESS_DUMP command invokes the OpenVMS debugger to display a process dump file for either an Alpha or a VAX image. For a complete description of the debugger, including information about the DEBUG command, see the HP OpenVMS Debugger Manual.
Requires read (R) access to the dump file.
ANALYZE/PROCESS_DUMP dump-file
dump-file
Specifies the dump file to be analyzed with the debugger.
The ANALYZE/PROCESS_DUMP command examines the dump file of an image that failed during execution. The OpenVMS Debugger is invoked automatically. To cause a dump file to be created for a process, you must use the /DUMP qualifier with the RUN command when invoking the image, or you must use the SET PROCESS/DUMP command before invoking the image. On Alpha systems, you can use the DUMP/PROCESS command.This section also applies to Alpha systems running Version 7.2 or before.
Other restrictions include the configuration of the control regions in P1 space, the process running at the time of the dump, and the process performing the ANALYZE/PROCESS_DUMP command. The location of the base of the user stack for each process, which depends on the size of allocated space, determines whether the processes are compatible. The size of allocated space for the process analyzing the dump must be less than the size of allocated space for the process that created the dump. If you are analyzing the dump on a different system, but with the same version of the operating system, you can decrease the size of allocated space by modifying one or more of the system parameters that affect the size of allocated space.
You can modify the system parameter IMGIOCNT dynamically. Other parameters to adjust allocated space require a reboot of the system.
On Alpha systems, the system parameter IMGREG_PAGES is likely to cause a problem with allocated size. When a dump comes from a system without DECwindows and is examined on a system with DECwindows, a P1 message is displayed. DECwindows requires IMGREG_PAGES to be at least 2000 pages, which means that the value is too large by 1200 to 1400 pages.
Also on Alpha systems, in some cases, the OpenVMS Debugger is incapable of analyzing the dumped image. For example, when the dumped image's PC is set to an invalid address or when the dumped image's stack is corrupted by a bad process descriptor, you must use the Delta Debugger (DELTA) to analyze the dump. To use DELTA as the debugger, you must install the SYS$LIBRARY:DELTA image by invoking the Install utility. For complete information on the Install utility, see the HP OpenVMS System Management Utilities Reference Manual.
This section applies to OpenVMS Alpha systems running Version 7.3 or greater.
You can now analyze a dump file on a system other than where the dump was generated. However, if the base image link date and time are not the same, you will need to also copy the file, SYS$BASE_IMAGE.EXE from the generating system, and point to it using the logical, SDA$READ_DIR. For example:
$ COPY other_node::SYS$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE my_disk$:[my_dir] $ DEFINE/USER SDA$READ_DIR my_disk$:[my_dir],SYS$SYSROOT:[SYS$LDR],SYS$SYSROOT:[SYSLIB] $ ANALYZE/PROCESS_DUMP mycrash.dmpIf you are analyzing a threaded process dump on a system other than the system on which it was generated, you may also need to copy and point to PTHREAD$RTL and PTHREAD$DBGSHR (DECthread debug assistant) on the generating system. For example:
$ COPY other_node::SYS$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE my_disk$:[my_dir] $ COPY other_node::SYS$SHARE:PTHREAD$RTL.EXE my_disk$:[my_dir] $ COPY other_node::SYS$SHARE:PTHREAD$DBGSHR.EXE my_disk$:[my_dir] $ DEFINE/USER SDA$READ_DIR my_disk$:[my_dir],SYS$SYSROOT:[SYS$LDR],SYS$SYSROOT:[SYSLIB] $ DEFINE/USER PTHREAD$RTL my_disk$:[my_dir]PTHREAD$RTL.EXE $ DEFINE/USER PTHREAD$DBGSHR my_disk$:[my_dir]PTHREAD$DBGSHR.EXE $ ANALYZE/PROCESS_DUMP mycrash.dmpIf you are unable to analyze a process dump with the debugger, then you should attempt to use the System Dump Analyzer (SDA) utility. See the ANALYZE/CRASH command in online help for more information. For example:
$ ANALYZE/CRASH mycrash.dmp OpenVMS (TM) Alpha system dump analyzer ...analyzing a compressed process dump... Dump taken on 19-OCT-1999 12:03:40.95 SDA> .. . .
/FULL
On VAX and Alpha systems, shows the information that is displayed by the following debugger commands: SHOW IMAGE, SHOW THREAD/ALL, and SHOW CALL./IMAGE=dump-file
On VAX systems, specifies the image to be activated to set up the process context for the analysis. If you use the /NOIMAGE qualifier, the DELTA debugger will be used for the analysis.By default, symbols are taken from the image with the same name as the image that was running at the time of the dump.
/IMAGE_PATH[=directory-spec] dump-file
/NOIMAGE_PATH
On Alpha systems, specifies the search path the debugger is to use to find the debugger symbol table (DST) file. As in prior debuggers, the debugger builds an image list from the saved process image list. When you set an image (the main image is automatically set), the debugger attempts to open that image in order to find the DST file.If you include the /IMAGE_PATH=directory-spec qualifier, the debugger searches for the DST file in the specified directory. The debugger first tries to translate directory-spec as the logical name of a directory search list. If that fails, the debugger interprets directory-spec as a directory specification, and searches that directory for matching .DSF or .EXE files. A .DSF file takes precedence over an .EXE file. The name of the .DSF or .EXE file must match the image.
If you do not include the /IMAGE_PATH=directory-spec qualifier, the debugger looks for the DST file first in the directory that contains the dump file. If that fails, the debugger searches directory SYS$SHARE and then directory SYS$MESSAGE. If the debugger fails to find a DST file for an image, the symbolic information available to the debugger is limited to global and universal symbol names.
Version 7.3 and later debuggers check for dumpfile image specification and DST file link date-time mismatches and issue a warning if one is discovered.
The dump-file parameter is the name of the process dump file to be analyzed. Note that the process dump file file type must be .DMP and the DST file type must be either .DSF or .EXE.
Restrictions
You cannot use a logical to redirect the search for an image and use the /IMAGE_PATH qualifier at the same time. If you use the /IMAGE_PATH qualifier, then all images that are not in their original locations must be found through that path. Individual image logicals (for example, the "SH" in "DEFINE SH SYS$LOGIN:SH.EXE") are not processed.Additionally, you cannot input a directory search path directly to the /IMAGE_PATH qualifier, as it does not process a directory list separated by commas; however, you can specify a logical that translates into a directory search path.
/INTERACTIVE
/NOINTERACTIVE (default)
On VAX systems, causes the display of information to pause when your terminal screen is filled. Press Return to display additional information. By default, the display is continuous./MISCELLANEOUS
On VAX systems, displays process information and registers at the time of the dump. See the $GETJPI system service for further explanation of the process information displayed./RELOCATION
On VAX systems, displays the addresses to which data structures saved in the dump are mapped in P0 space. (Examples of such data structures are the stacks.) The data structures in the dump must be mapped into P0 space so that the debugger can use those data structures in P1 space.
#1 |
---|
$ ANALYZE/PROCESS/FULL ZIPLIST R0 = 00018292 R1 = 8013DE20 R2 = 7FFE6A40 R3 = 7FFE6A98 R4 = 8013DE20 R5 = 00000000 R6 = 7FFE7B9A R7 = 0000F000 R8 = 00000000 R9 = 00000000 R10 = 00000000 R11 = 00000000 SP = 7FFAEF44 AP = 7FFAEF48 FP = 7FFAEF84 FREE_P0_VA 00001600 FREE_P1_VA 7FFAC600 Active ASTs 00 Enabled ASTs 0F Current Privileges FFFFFF80 1010C100 Event Flags 00000000 E0000000 Buffered I/O count/limit 6/6 Direct I/O count/limit 6/6 File count/limit 27/30 Process count/limit 0/0 Timer queue count/limit 10/10 AST count/limit 6/6 Enqueue count/limit 30/30 Buffered I/O total 7 Direct I/O total 18 Link Date 27-DEC-2001 15:02:00.48 Patch Date 17-NOV-2001 00:01:53.71 ECO Level 0030008C 00540040 00000000 34303230 Kernel stack 00000000 pages at 00000000 moved to 00000000 Exec stack 00000000 pages at 00000000 moved to 00000000 Vector page 00000001 page at 7FFEFE00 moved to 00001600 PIO (RMS) area 00000005 pages at 7FFE1200 moved to 00001800 Image activator context 00000001 page at 7FFE3400 moved to 00002200 User writable context 0000000A pages at 7FFE1C00 moved to 00002400 Creating a subprocess VAX DEBUG Version 5.4 DBG> |
This example shows the output of the ANALYZE/PROCESS command when used with the /FULL qualifier on a VAX system. The file specified, ZIPLIST, contains the dump of a process that encountered a fatal error. The DBG> prompt indicates that the debugger is ready to accept commands.
#2 |
---|
$ ANALYZE/PROCESS/FULL WECRASH.DMP OpenVMS Alpha Debug64 Version X7.3-010 %SYSTEM-F-IMGDMP, dynamic image dump signal at PC=001D0F8CB280099C, PS=001D0028 break on unhandled exception preceding WECRASH\th_run\%LINE 26412 in THREAD 8 %DEBUG-W-UNAOPNSRC, unable to open source file DSKD$:[IMGDMP]WECRASH.C;11 -RMS-F-DEV, error in device name or inappropriate device type for operation 26412: Source line not available image name set base address end address CMA$TIS_SHR no 000000007B8CA000 000000007B8D7FFF CODE0 FFFFFFFF80500000 FFFFFFFF805033FF DATA1 000000007B8CA000 000000007B8CB3FF DATA2 000000007B8CC000 000000007B8D13FF DATA3 000000007B8D2000 000000007B8D21FF DATA4 000000007B8D4000 000000007B8D41FF DATA5 000000007B8D6000 000000007B8D63FF DECC$SHR no 000000007BE7A000 000000007BF0DFFF CODE0 FFFFFFFF8055C000 FFFFFFFF806C9DFF DATA1 000000007BE7A000 000000007BEACFFF DATA2 000000007BEBA000 000000007BEC2DFF DATA3 000000007BECA000 000000007BED77FF DATA4 000000007BEDA000 000000007BEDA9FF DATA5 000000007BEEA000 000000007BEEA1FF DATA6 000000007BEFA000 000000007BEFE7FF DATA7 000000007BF0A000 000000007BF0D1FF DPML$SHR no 000000007BB92000 000000007BBD1FFF CODE0 FFFFFFFF80504000 FFFFFFFF8055B5FF DATA1 000000007BB92000 000000007BBAC1FF DATA2 000000007BBAE000 000000007BBBDBFF DATA3 000000007BBBE000 000000007BBBE1FF DATA4 000000007BBC0000 000000007BBCC9FF DATA5 000000007BBCE000 000000007BBCE3FF DATA6 000000007BBD0000 000000007BBD07FF LIBOTS no 000000007B5AA000 000000007B5B1FFF DATA1 000000007B5AA000 000000007B5AC5FF DATA2 000000007B5AE000 000000007B5AFBFF DATA3 000000007B5B0000 000000007B5B01FF LIBRTL no 000000007B558000 000000007B5A9FFF CODE0 FFFFFFFF8041C000 FFFFFFFF804BD7FF DATA1 000000007B558000 000000007B5669FF DATA2 000000007B568000 000000007B5697FF DATA3 000000007B578000 000000007B5845FF DATA4 000000007B588000 000000007B5881FF DATA5 000000007B598000 000000007B59A5FF DATA6 000000007B5A8000 000000007B5A99FF PTHREAD$RTL no 000000007BBD2000 000000007BC27FFF DATA0 000000007BBD2000 000000007BBDA1FF DATA1 000000007BBDC000 000000007BBDF3FF DATA2 000000007BBE0000 000000007BBE2FFF DATA3 000000007BBE4000 000000007BC1E1FF DATA4 000000007BC20000 000000007BC20BFF DATA5 000000007BC22000 000000007BC247FF DATA6 000000007BC26000 000000007BC275FF *WECRASH yes 0000000000010000 00000000000403FF total images: 7 Thread Name State Substate Policy Pri ------ ------------------------- --------------- ----------- ------------ --- 1 default thread blocked join 2 SCHED_OTHER 11 2 thread 0: counting ready VP 0 SCHED_OTHER 11 3 thread 1: dumping ready VP 0 SCHED_OTHER 11 4 thread 2 blocked delay SCHED_OTHER 11 5 thread 3 blocked delay SCHED_OTHER 11 6 thread 4 blocked delay SCHED_OTHER 11 7 thread 5: counting ready VP 0 SCHED_OTHER 11 8 thread 6: dumping running SCHED_OTHER 11 9 thread 7 blocked delay SCHED_OTHER 11 10 thread 8 blocked delay SCHED_OTHER 11 11 thread 9 blocked delay SCHED_OTHER 11 module name routine name line rel PC abs PC *WECRASH th_run 26411 0000000000000244 0000000000030244 SHARE$PTHREAD$RTL_DATA0 000000000001F15C 000000007BC0315C SHARE$PTHREAD$RTL_DATA0 000000000000F494 000000007BBF3494 0000000000000000 0000000000000000 ----- the above looks like a null frame in the same scope as the frame below SHARE$PTHREAD$RTL_DATA0 ? ? DBG> DBG> set source/latest sys$disk:[] DBG> examine/source .pc-4 module WECRASH 26411: lib$signal(SS$_IMGDMP); DBG> |
This example shows the output of the ANALYZE/PROCESS command on a multithreaded process dump, using the /FULL qualifier on an Alpha system.
Previous | Next | Contents | Index |