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