[Digital logo]
[HR]

OpenVMS Alpha System Dump Analyzer Utility Manual


Previous | Contents

The system manager can use the SDA COPY command or the DCL COPY command. Either command can be used in a site-specific startup procedure, but the SDA COPY command is preferred because it marks the dump file as copied. As mentioned earlier, this is particularly important if the dump was written into the page file, SYS$SYSTEM:PAGEFILE.SYS, because it releases those pages occupied by the dump to the pager. Another advantage of using the SDA COPY command is that this command copies only the saved number of blocks and not necessarily the whole allotted dump file. For instance, if the size of the SYSDUMP.DMP file is 100,000 blocks and the bugcheck wrote only 60,000 blocks to the dump file, then DCL COPY would create a file of 100,000 blocks. However, SDA COPY would generate a file of only 60,000 blocks.

Because system dump files are set to NOBACKUP, the Backup utility (BACKUP) does not copy them to tape unless you use the qualifier /IGNORE=NOBACKUP when invoking BACKUP. When you use the SDA COPY command to copy the system dump file to another file, OpenVMS Alpha does not set the new file to NOBACKUP.

As shipped by Digital, the file SYS$SYSTEM:SYSDUMP.DMP is protected against world access. Because a dump file can contain privileged information, Digital recommends that the system manager not change this default protection.

2.3 Invoking SDA when Rebooting the System

When the system reboots after a system failure, SDA is automatically invoked by default. SDA archives information from the dump in a history file. In addition, a listing file with more detailed information about the system failure is created in the directory pointed to by the logical name CLUE$COLLECT. (Note that the default directory is SYS$ERRORLOG unless you redefine the logical name CLUE$COLLECT in the procedure SYS$MANAGER:SYLOGICALS.COM.) The file name is in the form CLUE$node_ddmmyy_hhmm.LIS where the timestamp (hhmm) corresponds to the system failure time and not the time when the file was created.

Directed by commands in a site-specific file, SDA can take additional steps to record information about the system failure. They include the following:

The following example shows SDA commands that can make up your site-specific command file to produce a more complete SDA listing after each system failure, and to save a copy of the dump file:

 
! 
! SDA command file, to be executed as part of the system 
! bootstrap from within CLUE. Commands in this file can 
! be used to save the dump file after a system bugcheck, and 
! to execute any additional SDA commands. 
! 
 
! Note that the logical name DMP$ must have been defined 
! within SYS$MANAGER:SYLOGICALS.COM    
! 
READ/EXEC                   ! read in the executive images' symbol tables 
COPY DMP$:SAVEDUMP.DMP      ! copy and save dump file 
SHOW STACK                  ! display the stack 
! 
 

The SDA commands in this site-specific command file are executed first and then the CLUE HISTORY command is executed by default. See the reference section on CLUE HISTORY for details on the summary information that is generated and stored in the CLUE list file by the CLUE HISTORY command.

To point to your site-specific file, add a line such as the following to the file SYS$MANAGER:SYLOGICALS.COM:

$ DEFINE/SYSTEM CLUE$SITE_PROC SYS$MANAGER:SAVEDUMP.COM 

In this example, the site-specific file is named SAVEDUMP.COM.

The CLUE list file can be printed immediately or saved for later examination.

SDA is invoked and executes the specified commands only when the system boots immediately after a system failure. If the system is booting for any other reason (such as a normal system shutdown and reboot), SDA exits.

If CLUE files occupy more space than the threshold allows (the default is 5000 blocks), the oldest files will be deleted until the threshold limit is reached. The threshold limit can be customized with the CLUE$MAX_BLOCK logical name.

To prevent the running of CLUE at system startup, define the logical CLUE$INHIBIT in the SYLOGICALS.COM file as /SYS TRUE.

3 Analyzing a System Dump

SDA performs certain tasks before bringing a dump into memory, presenting its initial displays, and accepting command input. These tasks include the following:

For detailed information on investigating system failures, see Section 7.

3.1 Requirements

To analyze a dump file, your process must have read access both to the file that contains the dump and to copies of SDA$READ_DIR:SYS$BASE_IMAGE.EXE and SDA$READ_DIR:REQSYSDEF.STB (the required subset of the symbols in the file SYSDEF.STB). SDA reads these tables by default.

3.2 Invoking SDA

If your process can access the files listed in Section 3.1, you can issue the DCL command ANALYZE/CRASH_DUMP to invoke SDA. If you do not specify the name of a dump file in the command, SDA prompts you:

$ ANALYZE/CRASH_DUMP
_Dump File:

The default file specification is as follows:

SYS$DISK and [default-dir] represent the disk and directory specified in your last SET DEFAULT command.

If you are rebooting after a system failure, SDA is automatically invoked. See Section 2.3.

3.3 Mapping the Contents of the Dump File

SDA first attempts to map the contents of physical memory as stored in the specified dump file. To do this, it must first locate the system page table (SPT) among its contents. The SPT contains one entry for each page of system virtual address space.

Under certain conditions, some memory locations might not be saved in the system dump file. Additionally, if a bugcheck occurs during system initialization, the contents of the register display may be unreliable. The symptom of such a bugcheck is a SHOW SUMMARY display that shows no processes or only the swapper process.

If you use an SDA command to access a virtual address that has no corresponding physical address, SDA generates the following error message:

%SDA-E-NOTINPHYS, 'location': virtual data not in physical memory 

When analyzing a selective dump file, if you use an SDA command to access a virtual address that has a corresponding physical address not saved in the dump file, SDA generates the following error message:

%SDA-E-MEMNOTSVD, memory not saved in the dump file 

3.4 Building the SDA Symbol Table

After locating and reading the system dump file, SDA attempts to read the system symbol table file into the SDA symbol table. If SDA cannot find SDA$READ_DIR:SYS$BASE_IMAGE.EXE---or is given a file that is not a system symbol table in the /SYMBOL qualifier to the ANALYZE command---it displays a fatal error and exits. SDA also reads into its symbol table a subset of SDA$READ_DIR:SYSDEF.STB, called SDA$READ_DIR:REQSYSDEF.STB. This subset provides SDA with the information needed to access some of the data structures in the dump.

When SDA finishes building its symbol table, SDA displays a message identifying itself and the immediate cause of the system failure. In the following example, the cause of the system failure was the deallocation of a bad page file address.

OpenVMS Alpha System Dump Analyzer 
 
Dump taken on 27-MAR-1993  11:22:33.92 
BADPAGFILD, Bad page file address deallocated 

3.5 Executing the SDA Initialization File (SDA$INIT)

After displaying the system failure summary, SDA executes the commands in the SDA initialization file, if you have established one. SDA refers to its initialization file by using the logical name SDA$INIT. If SDA cannot find the file defined as SDA$INIT, it searches for the file SYS$LOGIN:SDA.INIT.

This initialization file can contain SDA commands that read symbols into SDA's symbol table, define keys, establish a log of SDA commands and output, or perform other tasks. For instance, you may want to use an SDA initialization file to augment SDA's symbol table with definitions helpful in locating system code. If you issue the following command, SDA includes those symbols that define many of the system's data structures, including those in the I/O database:

READ SDA$READ_DIR:filename 

You may also find it helpful to define those symbols that identify the modules in the images that make up the executive by issuing the following command:

READ/EXECUTIVE SDA$READ_DIR: 

After SDA has executed the commands in the initialization file, it displays its prompt as follows:

SDA> 

This prompt indicates that you can use SDA interactively and enter SDA commands.

An SDA initialization file may invoke a command procedure with the @ command. However, such command procedures cannot invoke other command procedures.

4 Analyzing a Running System

Occasionally, OpenVMS Alpha encounters an internal problem that hinders system performance without causing a system failure. By allowing you to examine the running system, SDA enables you to search for the solution without disturbing the operating system. For example, you may be able to use SDA to examine the stack and memory of a process that is stalled in a scheduler state, such as a miscellaneous wait (MWAIT) or a suspended (SUSP) state.

If your process has change-mode-to-kernel (CMKRNL) privilege, you can invoke SDA to examine the system. Use the following DCL command:

$ ANALYZE/SYSTEM

SDA attempts to load SDA$READ_DIR:SYS$BASE_IMAGE.EXE and SDA$READ_DIR:REQSYSDEF.STB. It then executes the contents of any existing SDA initialization file, as it does when invoked to analyze a crash dump (see Sections 3.4 and 3.5, respectively). SDA subsequently displays its identification message and prompt, as follows:

OpenVMS Alpha System Analyzer 
 
SDA> 

This prompt indicates that you can use SDA interactively and enter SDA commands. When analyzing a running system, SDA sets its process context to that of the process running SDA.

If you are analyzing a running system, consider the following:

5 SDA Context

When you invoke SDA to analyze either a crash dump or a running system, SDA establishes a default context for itself from which it interprets certain commands.

When you are analyzing a uniprocessor system, SDA's context is solely process context, which means SDA can interpret its process-specific commands in the context of either the process current on the uniprocessor or some other process in another scheduling state. When SDA is initially invoked to analyze a crash dump, SDA's process context defaults to that of the process that was current at the time of the system failure. When you invoke SDA to analyze a running system, SDA's process context defaults to that of the current process, that is, the one executing SDA. To change SDA's process context, issue any of the following commands:

When you invoke SDA to analyze a crash dump from a multiprocessing system with more than one active CPU, SDA maintains a second dimension of context---its CPU context---that allows it to display certain processor-specific information. This information includes the reason for the bugcheck exception, the currently executing process, the current IPL, and the spin locks owned by the processor. When you invoke SDA to analyze a multiprocessor's crash dump, its CPU context defaults to that of the processor that induced the system failure. When you are analyzing a running system, CPU context is not accessible to SDA. Therefore, the SET CPU and SHOW CPU commands are not permitted.

You can change the SDA CPU context by using any of the following commands:

Changing CPU context involves an implicit change in process context in either of the following ways:

Changing process context can require a switch of CPU context as well. For instance, if you issue a SET PROCESS command for a process that was current at the time of a system failure on another CPU, SDA will automatically change its CPU context to that of the CPU on which that process was current. The following commands can have this effect if the process-name, pcb-address, or index number (nn) refers to a current process:

6 SDA Command Format

The following sections describe the format of SDA commands and the expressions you can use with SDA commands.

6.1 General Command Format

SDA uses a command format similar to that used by the DCL interpreter. Issue commands in the following format:

command-name[/qualifier...] [parameter][/qualifier...] [!comment] 

The command-name is an SDA command. Each command tells the utility to perform a function. Commands can consist of one or more words, and can be abbreviated to the number of characters that make the command unique. For example, SH stands for SHOW, and SE stands for SET.

The parameter is the target of the command. For example, SHOW PROCESS RUSKIN tells SDA to display the context of the process RUSKIN. The command EXAMINE 80104CD0;40 displays the contents of 40 bytes of memory, beginning with location 80104CD0.

When you supply part of a file specification as a parameter, SDA assumes default values for the omitted portions of the specification. The default device is SYS$DISK, the device specified in your most recent SET DEFAULT command. The default directory is the directory specified in the most recent SET DEFAULT command. See the OpenVMS DCL Dictionary for a description of the DCL command SET DEFAULT.

The qualifier modifies the action of an SDA command. A qualifier is always preceded by a slash (/). Several qualifiers can follow a single parameter or command name, but each must be preceded by a slash. Qualifiers can be abbreviated to the shortest string of characters that uniquely identifies the qualifier.

The comment consists of text that describes the command; this comment is not actually part of the command. Comments are useful for documenting SDA command procedures. When executing a command, SDA ignores the exclamation point and all characters that follow it on the same line.

6.2 Expressions

You can use expressions as parameters for some SDA commands, such as SEARCH and EXAMINE. To create expressions, use any of the following elements:

Numerals are one possible component of an expression. The following sections describe the use of the other components.

6.2.1 Radix Operators

Radix operators determine which numeric base SDA uses to evaluate expressions. You can use one of the three radix operators to specify the radix of the numeric expression that follows the operator:

The default radix is hexadecimal. SDA displays hexadecimal numbers with leading zeros and decimal numbers with leading spaces.

6.2.2 Arithmetic and Logical Operators

There are two types of arithmetic and logical operators, both of which are listed in Table SDA-3.

In evaluating expressions containing binary operators, SDA performs logical AND, OR, and XOR operations, and multiplication, division, and arithmetic shifting before addition and subtraction. Note that the SDA arithmetic operators perform integer arithmetic on 64-bit operands.

Table SDA-3 SDA Operators
Operator Action
Unary Operators
# Performs a logical NOT of the expression.
+ Makes the value of the expression positive.
-- Makes the value of the expression negative.
@ Evaluates the following expression as an address, then uses the contents of that address as value.
^Q When used with the unary operator @, it specifies the size of field to be used as an address is a quadword ¹.
^L When used with the unary operator @, it specifies the size of field to be used as an address is a longword².
^W When used with the unary operator @, it specifies the size of field to be used as an address is a word³.
^B When used with the unary operator @, it specifies the size of field to be used as an address is a byte 4.
^P When used with the unary operator @, it specifies a physical address 5.
^V When used with the unary operator @, it specifies a virtual address 6.
G Adds FFFFFFFF 80000000 16 to the value of the expression 7.
H Adds 7FFE0000 16 to the value of the expression 8.
I Fills the leading digits of the following hexadecimal number with hex value of F. For example:
SDA> eval i80000000
      
Hex = FFFFFFFF.80000000 Decimal = -2147483648 G
SYS$PUBLIC_VECTORS_NPRO
Binary Operators
+ Addition
-- Subtraction
* Multiplication
& Logical AND
| Logical OR
\ Logical XOR
/ Division 9
@ Arithmetic shifting
"." Catenates two 32-bit values into a 64-bit value. For example:
SDA> eval fe.50000
      
Hex = 000000FE00050000 Decimal = 1090922020864


¹The command SET FETCH QUADWORD provides the same effect on all subsequent uses of unary operator @ as if ^Q were added each time. That is, SET FETCH is making it the default. For an example of the use of ^Q, see the SET FETCH command.
²The command SET FETCH LONGWORD provides the same effect on all subsequent uses of unary operator @ as if ^L were added each time. That is, SET FETCH is making it the default. For an example of the use of ^L, see the SET FETCH command.
³The command SET FETCH WORD provides the same effect on all subsequent uses of unary operator @ as if ^W were added each time. That is, SET FETCH is making it the default. For an example of the use of ^W, see the SET FETCH command.
4The command SET FETCH BYTE provides the same effect on all subsequent uses of unary operator @ as if ^B were added each time. That is, SET FETCH is making it the default. For an example of the use of ^B, see the SET FETCH command.
5The command SET FETCH PHYSICAL provides the same effect on all subsequent uses of unary operator @ as if ^P were added each time. That is, SET FETCH is making it the default. For an example of the use of ^P, see the SET FETCH command.
6The command SET FETCH VIRTUAL provides the same effect on all subsequent uses of unary operator @ as if ^V were added each time. That is, SET FETCH is making it the default. For an example of the use of ^V, see the SET FETCH command.
7The unary operator G corresponds to the first virtual address in system space. For example, the expression GD40 can be used to represent the address FFFFFFFF 80000D4016.
8The unary operator H corresponds to a convenient base address in P1 space (7FFE000016). You can therefore refer to an address such as 7FFE2A6416 as H2A64.
9In division, SDA truncates the quotient to an integer, if necessary, and does not retain a remainder.

6.2.3 Precedence Operators

SDA uses parentheses as precedence operators. Expressions enclosed in parentheses are evaluated first. SDA evaluates nested parenthetical expressions from the innermost to the outermost pairs of parentheses.

6.2.4 Symbols

A symbol can represent a few different types of values. It can represent a constant, a data address, a procedure descriptor address, or a routine address. Constants are usually offsets of a particular field in a data structure; however, they can also represent constant values such as the BUG$_xxx symbols.

All address symbols identify memory locations. SDA generally does not distinguish among different types of address symbols. However, for a symbol identified as the name of a procedure descriptor, SDA takes an additional step of creating an associated symbol to name the code entry point address of the procedure. It forms the code entry point symbol name by appending _C to the name of the procedure descriptor.

Also, SDA substitutes the code entry point symbol name for the procedure descriptor symbol when you enter the following command:

SDA> EXAMINE/INSTRUCTION procedure descriptor

For example, enter the following command:

SDA> EXAMINE/INSTRUCTION SCH$QAST

SDA displays the following information:

SCH$QAST_C:     SUBQ    SP,#X40,SP 

Now enter the EXAMINE command but do not specify the /INSTRUCTION qualifier, as follows:

SDA> EXAMINE SCH$QAST

SDA displays the following information:

SCH$QAST:  0000002C.00003009   ".0..,..." 

This display shows the contents of the first two longwords of the procedure descriptor.


Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]

[HR]

  6135P001.HTM
  OSSG Documentation
  22-NOV-1996 14:11:47.52

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal