![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The reason is that the debugger steps over routines by searching for a RET instruction to be executed; however, the Fortran compiler deallocates temporary strings used in Fortran RTL I/O routines from the stack in a nonstandard way, without an explicit RET instruction.
To recover from the error message, issue several STEP commands to return the session to the expected line of code. To prevent recurrence of the problem, modify your program to include a temporary variable that stores the results of the function prior to the I/O statement. For example:
CHARACTER*23 c1, c2
c1 = c2() ! c1 is the temporary variable
WRITE (*) c1
END
C
CHARACTER*23 FUNCTION c2()
c2 = 'ABCDEFGHIJKLMNOPQRSTUVW'
RETURN
END
The debugger allocates a certain amount of memory at startup and shares the stack with the user's program. If a user process exception results in exhaustion of resources or corruption of the stack, the debugger may be incapable of regaining control, and the debug session may terminate.
Be aware of this potential behavior after the occurrence of stack corruption messages or warnings about continuing from a severe error. In either case, the integrity of the debug session cannot be guaranteed.
It is recommended that you try one of the following measures:
A condition handler is a procedure that the operating system executes when an exception occurs.
Exceptions include hardware conditions (such as an arithmetic overflow or a memory access violation) or signaled software exceptions (for example, an exception signaled because a file could not be found).
Operating system conventions specify how, and in what order, various condition handlers established by the operating system, the debugger, or your own program are invoked---for example, the primary handler, call frame (application-declared) handlers, and so on. Section 13.5.3 describes condition handling when you are using the debugger. See the OpenVMS Run-Time Library Routines Volume for additional general information about condition handling.
Tools for debugging exceptions and condition handlers include the following:
When you enter a SET BREAK/EXCEPTION or SET TRACE/EXCEPTION command, you direct the debugger to treat any exception generated by your program as a breakpoint or tracepoint. As a result of a SET BREAK/EXCEPTION command, if your program generates an exception, the debugger suspends execution, reports the exception and the line where execution is paused, and prompts for commands. The following example shows the effect:
DBG> SET BREAK/EXCEPTION
DBG> GO
.
.
.
%SYSTEM-F-INTDIV, arithmetic trap, integer divide by zero at PC=0000066C, PSL=03C00022
break on exception preceding TEST\%LINE 13
6: X := 3/Y;
DBG>
Note that an exception breakpoint (or tracepoint) is triggered even if your program has a condition handler to handle the exception. The SET BREAK/EXCEPTION command causes a breakpoint to occur before any handler can execute (and possibly dismiss the exception). Without the exception breakpoint, the handler will be executed, and the debugger would get control only if no handler dismissed the exception (see Section 13.5.2 and Section 13.5.3).
The following command line is useful for identifying where an exception occurred. It causes the debugger to automatically display the sequence of active calls and the PC value at an exception breakpoint:
DBG> SET BREAK/EXCEPTION DO (SET MODULE/CALLS; SHOW CALLS)
You can also create a screen-mode DO display that issues a SHOW CALLS command whenever the debugger interrupts execution. For example:
DBG> DISPLAY CALLS DO (SET MODULE/CALLS; SHOW CALLS)
An exception tracepoint (established with the SET TRACE/EXCEPTION command) is like an exception breakpoint followed by a GO command without an address expression specified.
An exception breakpoint cancels an exception tracepoint, and vice versa.
To cancel exception breakpoints or tracepoints, use the CANCEL BREAK/EXCEPTION or CANCEL TRACE/EXCEPTION command, respectively.
When an exception breakpoint is triggered, execution is paused before any application-declared condition handler is invoked. When you resume execution from the breakpoint with the GO, STEP, or CALL commands, the behavior is as follows:
The following Fortran example shows how to determine the presence of a condition handler at an exception breakpoint and how a STEP command, entered at the breakpoint, enables you to step into the handler.
At the exception breakpoint, the SHOW CALLS command indicates that the exception was generated during a call to routine SYS$QIOW:
DBG> SET BREAK/EXCEPTION
DBG> GO
.
.
.
%SYSTEM-F-SSFAIL, system service failure exception, status=0000013C, PC=7FFEDE06, PSL=03C00000
break on exception preceding SYS$QIOW+6
DBG> SHOW CALLS
module name routine name line rel PC abs PC
SYS$QIOW 00000006 7FFEDE06
*EXC$MAIN EXC$MAIN 23 0000003B 0000063B
DBG>
On VAX processors, the following SHOW STACK command indicates that no handler is declared in routine SYS$QIOW. However, one level down the call stack, routine EXC$MAIN has declared a handler named SSHAND:
DBG> SHOW STACK
stack frame 0 (2146296644)
condition handler: 0
SPA: 0
S: 0
mask: ^M<R2,R3,R4,R5,R6,R7,R8,R9,R10,R11>
PSW: 0020 (hexadecimal)
saved AP: 2146296780
saved FP: 2146296704
saved PC: EXC$MAIN\%LINE 25
.
.
.
stack frame 1 (2146296704)
condition handler: SSHAND
SPA: 0
S: 0
mask: ^M<R11>
PSW: 0000 (hexadecimal)
saved AP: 2146296780
saved FP: 2146296760
saved PC: SHARE$DEBUG+2217
.
.
.
At this exception breakpoint, entering a STEP command enables you to step directly into condition handler SSHAND:
DBG> STEP
stepped to routine SSHAND
2: INTEGER*4 FUNCTION SSHAND (SIGARGS, MECHARGS)
DBG> SHOW CALLS
module name routine name line rel PC abs PC
*SSHAND SSHAND 2 00000002 00000642
----- above condition handler called with exception 0000045C:
%SYSTEM-F-SSFAIL, system service failure exception, status=0000013C, PC=7FFEDE06, PSL=03C00000
----- end of exception message
SYS$QIOW 00000006 7FFEDE06
*EXC$MAIN EXC$MAIN 23 0000003B 0000063B
DBG>
The debugger symbolizes the addresses of condition handlers into names if that is possible. However, note that with some languages, exceptions are first handled by a Run-Time Library (RTL) routine, before any application-declared condition handler is invoked. In such cases, the address of the first condition handler might be symbolized to an offset from an RTL shareable image address.
When you run your program with the debugger, at least one of the following condition handlers is invoked, in the order given, to handle any exceptions caused by the execution of your program:
A handler can return one of the following three status codes to the Condition Handling Facility:
For more information about condition handling, see the OpenVMS Programming Concepts Manual.
When you run your program with the debugger, the primary handler is the debugger. Therefore, the debugger has the first opportunity to handle an exception, whether or not the exception is caused by the debugger.
If you enter a SET BREAK/EXCEPTION or SET TRACE/EXCEPTION command, the debugger breaks on (or traces) any exceptions caused by your program. The break (or trace) action occurs before any application-declared handler is invoked.
If you do not enter a SET BREAK/EXCEPTION or SET TRACE/EXCEPTION command, the primary handler resignals any exceptions caused by your program.
The secondary handler is used for special purposes and does not apply to the types of programs covered in this manual.
Each routine of your program can establish a condition handler, also known as a call-frame handler. The operating system searches for these handlers starting with the routine that is currently executing. If no handler was established for that routine, the system searches for a handler established by the next routine down the call stack, and so on back to the main program, if necessary.
After it is invoked, a handler might perform one of the following actions:
These handlers are controlled by the debugger. They enable the debugger to regain control and display the DBG> prompt if no application-declared handler has handled an exception. Otherwise, the debugging session will terminate and control will pass to the DCL command interpreter.
The final handler is the last frame on the call stack and the first of these two handlers to be invoked. The following example shows what happens when an unhandled exception is propagated from an exception breakpoint to the final handler:
DBG> SET BREAK/EXCEPTION
DBG> GO
.
.
.
%SYSTEM-F-INTDIV, arithmetic trap, integer divide by zero at PC=0000066C, PSL=03C00022
break on exception preceding TEST\%LINE 13
6: X := 3/Y;
DBG> GO
%SYSTEM-F-INTDIV, arithmetic trap, integer divide by zero at PC=0000066C, PSL=03C00022
DBG>
In this example, the first INTDIV message is issued by the primary handler, and the second is issued by the final handler, which then displays the DBG> prompt.
The last-chance handler is invoked only if the final handler cannot gain control because the call stack is corrupted. For example:
DBG> DEPOSIT %FP = 10 DBG> GO . . . %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000A, PC=0000319C, PSL=03C00000 %DEBUG-E-LASTCHANCE, stack exception handlers lost, re-initializing stack DBG>
The catchall handler, which is part of the operating system, is invoked if the last-chance handler cannot gain control. The catchall handler produces a register dump. This should never occur if the debugger has control of your program, but it can occur if your program encounters an error when running without the debugger.
If, during a debugging session, you observe a register dump and are returned to DCL level ($), contact your Digital support representative.
When an exception is signaled, the debugger sets the following exception-related built-in symbols:
| Symbol | Description |
|---|---|
| %EXC_FACILITY | Name of facility that issued the current exception |
| %EXC_NAME | Name of current exception |
| %ADAEXC_NAME | Ada exception name of current exception (for Ada programs only) |
| %EXC_NUMBER | Number of current exception |
| %EXC_SEVERITY | Severity code of current exception |
You can use these symbols as follows:
The following examples show the use of some of these symbols. Note that the conditional expressions in the WHEN clauses are language-specific.
DBG> EVALUATE %EXC_NAME 'ACCVIO' DBG> SET TRACE/EXCEPTION WHEN (%EXC_NAME = "ACCVIO") DBG> EVALUATE %EXC_FACILITY 'SYSTEM' DBG> EVALUATE %EXC_NUMBER 12 DBG> EVALUATE/CONDITION_VALUE %EXC_NUMBER %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=FFFFFF30, PC=00007552, PSL=03C00000 DBG> SET BREAK/EXCEPTION WHEN (%EXC_NUMBER = 12) DBG> SET BREAK/EXCEPTION WHEN (%EXC_SEVERITY .NE. "I" .AND. %EXC_SEVERITY .NE. "S")
Exit handlers are procedures that are called whenever an image requests the $EXIT system service or runs to completion. A user program can declare one or more exit handlers. The debugger always declares its own exit handler.
At program termination, the debugger exit handler executes after all application-declared exit handlers have executed.
To debug an application-declared exit handler:
The SHOW EXIT_HANDLERS command gives a display of the exit handlers that your program has declared. The exit handler routines are displayed in the order that they are called. A routine name is displayed symbolically, if possible. Otherwise, its address is displayed. The debugger's exit handlers are not displayed. For example:
DBG> SHOW EXIT_HANDLERS exit handler at STACKS\CLEANUP exit handler at BLIHANDLER\HANDLER1 DBG>
A program can use asynchronous system traps (ASTs) either explicitly or implicitly by calling system services or Run-Time Library (RTL) routines that call application-defined AST routines. Section 13.7.1 explains how to facilitate debugging by disabling and enabling the delivery of ASTs originating with your program.
Debugging AST-driven programs can be confusing because interrupts originating from the program being debugged can occur, but are not processed, while the debugger is running (processing commands, tracing execution, displaying information, and so on).
By default, the delivery of ASTs is enabled while the program is running. The DISABLE AST command disables the delivery of ASTs while the program is running and causes any such potential interrupts to be queued.
The delivery of ASTs is always disabled when the debugger is running.
If a static watchpoint is in effect, the debugger deactivates the static watchpoint, ASTs, and thread switching, just before a system service call. The debugger reactivates them just after the system service call completes. (For more information, see the SET WATCH command description.)
The ENABLE AST command reenables the delivery of ASTs, including any pending ASTs. The SHOW AST command indicates whether the delivery of ASTs is enabled or disabled.
To control the delivery of ASTs during the execution of a routine called with the CALL command, use the /[NO]AST qualifiers. The command CALL/AST enables the delivery of ASTs in the called routine. The command CALL/NOAST disables the delivery of ASTs in the called routine. If you do not specify /AST or /NOAST with the CALL command, the delivery of ASTs is enabled unless you have previously entered the DISABLE AST command.
On OpenVMS Alpha systems, the debugger does not support attempts to debug translated images. If you must debug a translated image, use the Delta/XDelta Debugger. For more information on this debugger, see the OpenVMS Delta/XDelta Debugger Manual.
Some programs that perform synchronization or communication can pose problems for debugging. In the following cases, a user application remains in HIB (hibernate) state:
To work around this problem, debug these application programs using the limited one-process mode, rather than the default or the multiprocess mode. To set up one-process mode, issue the following command:
$ DEFINE DBG$PROCESS NONE
On OpenVMS systems, the debugger does not support attempts to debug inlined routines. If you attempt to debug an inlined routine, the debugger issues a message that it cannot access the routine, as shown in the following example:
%DEBUG-E-ACCESSR, no read access to address 00000000
To work around this problem, compile your program with the /NOOPTIMIZE qualifier.
This chapter describes features of the debugger that are specific to multiprocess programs (programs that run in more than one process). These features enable you to display process information and control the execution of specific processes. You can use these features in addition to those explained in other chapters.
The first section describes the two multiprocess models for multiprocess programs. Remaining sections detail the basic multiprocessing techniques, multiprocessing commands, and supplemental information.
Images discussed in this chapter are debuggable images---that is, images that can be brought under control of the debugger. A debuggable image is one that was not linked with the /NOTRACEBACK qualifier. As explained in Section 1.2, you have full symbolic information when debugging an image only if its modules were compiled and linked with the /DEBUG qualifier.
On OpenVMS Alpha systems, the debugger does not support attempts to debug translated images. If you must debug a translated image, use the Delta/XDelta Debugger. For more information on this debugger, see the OpenVMS Delta/XDelta Debugger Manual.
Multiprocessing programs conform to one of the following multiprocessing models:
Debugger multiprocessing features and commands support both multiprocessing models, but process relationships may differ depending on your invocation of the debugger.
This section gives an overview of the multiprocess debugging environment and explains the basic techniques used to debug a multiprocess program. Refer to subsequent sections for additional details.
Note
If a spawned process image has been linked with the /DEBUG qualifier, or if the SPAWN command runs the image with the /DEBUG qualifier, the parent process must (in the debugging session) spawn the child process with the NOWAIT flag set in the flags argument.
This section explains the usual way of starting a multiprocess debugging session. See Section 14.3.4 for additional techniques for starting the debugger by interrupting the execution of an image and bringing the image under debugger control (for example, using the Ctrl/Y--DEBUG sequence or the CONNECT command).
To start a multiprocess debugging session, follow these steps:
$ DEFINE/GROUP DBG$PROCESS MULTIPROCESS
$ DEBUG/KEEP
Debugger Banner and Version Number
DBG> RUN prog-name
Language: FORTRAN, Module: MAIN_PROG
Type GO to reach main program
predefined trace on activation at routine MAIN_PROG in %PROCESS_NUMBER 1
DBG_1>
DBG>
As with a one-process program, the debugger displays its banner, prompts for commands, and suspends execution just prior to the start of execution of the main image. However, note two differences:
The significance of the prompt suffix (_1) is explained Section 14.2.2.
In a multiprocess configuration, the debugger traces each new process that is brought under control. In this case, the debugger traces the first process, which runs the main image of the program. (%PROCESS_NUMBER is a built-in symbol that identifies a process number, just as %LINE identifies a line number.)
See Section 14.3.1 for more information about debugging configurations and process relationships. See Section 14.3.9 for system requirements related to multiprocess debugging.
The previous example shows that the debugger prompt in a multiprocess debugging configuration is different from that found in the default configuration (after the program is brought under debugger control).
In a multiprocess configuration, dynamic prompt setting is enabled by default (SET PROMPT/SUFFIX=PROCESS_NUMBER). Therefore, the prompt has a process-specific suffix that indicates the process number of the visible process. The debugger assigns a process number sequentially, starting with process 1, to each process that comes under the control of a given debugging session.
The visible process is the default context for issuing process-specific commands. Process-specific commands start execution (STEP, GO, and so on) and look up symbols, set breakpoints, look at the call stack and registers, and so on. Commands that are not process specific do not depend on the mapping of memory but, rather, affect the entire debugging environment (for example, keypad mode and screen mode commands).
4538P022.HTM OSSG Documentation 22-NOV-1996 13:02:04.46
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.