HP OpenVMS DCL Dictionary


Previous Contents Index


ANALYZE/PROCESS_DUMP

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 an Alpha 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.


Format

ANALYZE/PROCESS_DUMP dump-file


Parameter

dump-file

Specifies the dump file to be analyzed with the debugger.

Description

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.

For OpenVMS Alpha Systems

This section applies to Alpha systems running Version 7.2 or before.

Note

HP strongly recommends that you analyze a process dump on the system where the dump was generated. It is highly unlikely that you can analyze a dump successfully if you move the dump file to a different system.

Different configurations can cause the process executing the ANALYZE/PROCESS_DUMP command to fail to load the dumped image successfully. For example, if the systems have different versions of the operating system, the analysis might work, but it is not guaranteed.

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 running version 7.2 or before, 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, 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.dmp 

If 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.dmp 

If 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> .. 
. 
. 


Qualifiers

/FULL

On Alpha systems, shows the information that is displayed by the following debugger commands: SHOW IMAGE, SHOW THREAD/ALL, and SHOW CALL.

/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 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.


Examples

#1

$ 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