| Title: | DEBUG |
| Notice: | Updated locations for reporting QARs -- see note 834.1 |
| Moderator: | LOWFAT::DIETER |
| Created: | Fri Jan 24 1986 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1868 |
| Total number of notes: | 8200 |
I'm never quite sure if ANALYZE/PROCESS is owned by VMS engineering or
DEBUG (I'm sure that's just the way both groups want it too ;-).
I haven't had any comment in VMSNOTES about the following issue:
<<< VAXAXP::NOTES$:[NOTES$LIBRARY]VMSNOTES.NOTE;1 >>>
-< VAX and Alpha VMS - Digital Internal Use Only >-
================================================================================
Note 640.0 ANALYZE/PROCESS/IMAGE= => VA_IN_USE Alpha V7.1 1 reply
GIDDAY::GILLINGS "a crucible of informative mistakes" 136 lines 25-MAY-1997 20:53
--------------------------------------------------------------------------------
A customer has reported some unusual behaviour with ANALYZE/PROCESS
under OpenVMS/Alpha V7.1. While investigating, I've found some even
worse behaviour. Consider the following COBOL program:
IDENTIFICATION DIVISION.
PROGRAM-ID. TESTING.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 ST PIC X(10).
01 X PIC S9(09) COMP.
PROCEDURE DIVISION.
01-BEGIN.
MOVE "ABC" TO ST.
MOVE ST TO X.
STOP RUN.
If I compile and link as follows:
$ COBOL/NOOPT/DEBUG/CHECK=ALL TESTING
$ LINK TESTING
$ SET PROCESS/DUMP
$ DEFINE DBG$DECW$DISPLAY " " ! required on V7.1??
$ RUN TESTING
$ ANALYZE/PROCESS TESTING.DMP
Condition signalled to take dump:
%SYSTEM-F-DECINV, decimal invalid operand, PC=00000000000300CC, PS=0000001B
Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000004
Name = 000000000002D8BB
0025CB9400000000
0000001B0025CB94
000000040000001B
Register dump:
R0 = 0000000000000000 R1 = 0000000500000000 R2 = 0000000000236188
R3 = 000000007AF9F658 R4 = 000000007FFCF818 R5 = 000000007FFCF938
R6 = 000000007FFAC9F0 R7 = 000000007FFAC9F0 R8 = 000000007FFAC208
R9 = 000000007FFAC410 R10 = 000000007FFAD238 R11 = 000000007FFCE3E0
R12 = 000000007AF9FAA8 R13 = 000000007AF11660 R14 = 0000000000000000
R15 = 00000000009B4D47 R16 = 000000000002D8BB R17 = 0000000000000000
R18 = 000000007FFD0E88 R19 = 00000000002F0F00 R20 = 0000000000000120
R21 = 000000007FF87A80 R22 = 000000007FFBE008 R23 = 00000000002F0F00
R24 = 000000007FFBE000 R25 = 0000000000000002 R26 = 000000000025CB94
R27 = 0000000000233650 R28 = 100000000000001B R29 = 000000007AF9F410
SP = 000000007AF9F410 PC = 000000000025CB94 PS = 100000000000001B
Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
7AF91FE000010000
00382FE87AF91FE0
0000001B00382FE8
000000050000001B
Register dump:
R0 = 0000000000000000 R1 = 000000008273EED0 R2 = 0000000000392120
R3 = 000000007AF92070 R4 = 00000000003987A0 R5 = 00000000002ABA84
R6 = 0000000000000000 R7 = 0000000000000000 R8 = 0000000000000000
R9 = 00000000002351E8 R10 = 000000008273EED0 R11 = 000000007FFCE3E0
R12 = 000000007AF9FAA8 R13 = FFFFFFFF82875768 R14 = FFFFFFFF80F17D40
R15 = 00000000009B4D47 R16 = 000000007AF92070 R17 = FFFFFFFF8273EED0
R18 = 00000000002ABA84 R19 = FFFFFFFF8273EDA8 R20 = FFFFFFFFFFFFFFFF
R21 = 000000007FFEFDA0 R22 = 0000000000000018 R23 = 000000007AF93698
R24 = 000000007AF91000 R25 = 0000000000000002 R26 = 000000000038268C
R27 = 00000000003921B0 R28 = 0000000000000001 R29 = FFFFFFFF82F82830
SP = 000000007AFA0000 PC = 0000000000382FE8 PS = 000000000000001B
[This ACCVIO repeats forever - the process cannot be recovered from DCL.
although ^Y will give a prompt, any command which must exit the current
image will just restart the ACCVIO loop]
Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
7AF91FE000010000
00382FE87AF91FE0
Interrupt
$ stop
Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
7AF91FE000010000
00382FE87AF91FE0
0000001B00382FE8
000000050000001B
The only way out I've found is to terminate the process externally.
If I relink the image with /DEBUG and attempt to analyze the dump with
the /DEBUG image:
$ ANALYZE/PROCESS/IMAGE=TESTING_DBG TESTING.DMP
Condition signalled to take dump:
%SYSTEM-F-VA_IN_USE, virtual address already in use
LINKing the original image /DEBUG and RUN/NODEBUG will produce an
analyzable dump.
The practice of analyzing a dump using symbols from another image is
supported and widespread - that's what the /IMAGE qualifier is for!
Using RUN/NODEBUG is not always practical - especially for detached
processes.
In my experiments, I have not been able to generate a dump file which
I could analyze from a program linked /NODEBUG. I always get the looping
behaviour described above. Is it just my system (and my customers)?
Sample programs:
FORTRAN
PROGRAM ACCVIO
CALL LIB$SIGNAL(%VAL(12))
END
MACRO (in this case a "STOP" would successfully terminate the loop)
.title accvio
.psect $code,rd,nowrt,exe
.entry start,^m<>
pushl #12
CALLS #1,G^LIB$SIGNAL
RET
C
main(){lib$signal(12);}
My customer's primary concern is the VA_IN_USE error, but the ACCVIO
loop looks more serious to me!
John Gillings, Sydney CSC
================================================================================
Note 640.1 ANALYZE/PROCESS/IMAGE= => VA_IN_USE Alpha V7.1 1 of 1
GIDDAY::GILLINGS "a crucible of informative mistakes" 5 lines 25-MAY-1997 21:00
-< FT version? >-
--------------------------------------------------------------------------------
Just realized, the looping ACCVIO may be because the system I'm using
is Version H7.1 (the customer doesn't get that problem). I'll try and
find a real V7.1 system to test on. The VA_IN_USE is present on both
systems.
John Gillings, Sydney CSC
BTW: I've confirmed the looping ACCVIO is an artifact of the H7.1
system. I've now reproduced the VA_IN_USE error on a V7.1 system.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1867.1 | ana/proc problem...however, here's a work around | SSPADE::SSPADE::HILDE | Tue Jun 03 1997 15:54 | 149 | |
ANALYZE/PROCESS_DUMP is a VMS utility and is NOT owned by DEBUG.
ANALYZE/PROCESS_DUMP is setting up the environment, e.g. stack, memory,
registers, etc and calling DEBUG much like the image activator would
invoke DEBUG on a ^Y-DEBUG of an up and running program. Indeed the
debugger doesn't even know it is in a process dump recreation.
The ACCVIO looping behavior is disturbing. I can't reproduce it on a
regular V7.1 system and I guess you've decided that it is an artifact of
H7.1. The 000000000002D8BB signal that starts it out is just an
informational signalled from DEBUG during its startup/initialization.
It wants to say, "%DEBUG-I-SSINOTSET, system service interception is not
setup, defaulting to nostatic watchpoints"...again, it doesn't know that
it is a process dump recreation versus a real up and running program. I
suspect that the stack setup by ANALYZE/PROCESS_DUMP was improper and
DEBUG towards the end of its initialization is ACCVIOing while trying
to walk that stack to the exception context. I suspect that because of
the way DEBUG sets up its handlers and because of its over aggressive
or in some cases lack of internal error handling...it ends up sending itself
back to the stack walk for each ACCVIO, and thereby, back to the next ACCVIO.
The DEBUG internal error handling during startup was re-worked for V7.2
...I'm reasonably confident that this looping behavior will change to
a clean exit. Unfortuately, there is nothing DEBUG can do for the user
if it can't at least walk the stack back to the exception causing frame.
The %SYSTEM-F-VA_IN_USE is something that I believe comes out of
ANALYZE/PROCESS_DUMP...it certainly does NOT come from DEBUG. In these
cases ANALYZE/PROCESS_DUMP is quitting BEFORE invoking the debugger. My
understanding is that we should only see %SYSTEM-F-VA_IN_USE when a dump is
moved to and analyzed on a system with a virtual memory layout that is
incompatible with the layout on the system where the dump was generated. We
should not be seeing this on the same system...at least, that's my
understanding...but you are right, I can recreate this problem easily. To
me, it looks like ANALYZE/PROCESS_DUMP is doing something very wrong with
its /IMAGE switch.
I suggest that you enter a QAR or SPR (CLD?) against ANALYZE/PROC.
There is a little known work around, however, for this problem. Instead of
linking /DEBUG to get a image with debug info...link /DSF. That is, for
ALPHA, you can link a .DSF and a new .EXE. Note that you can't use the /DSF
/NOEXE combination (sigh) the linker will reject that and insist that you
generate a new EXE as well as the DSF. ALL the debug information is in
the .DSF file. (DSFs are usually used with the system code debugger, SCD,
for debugging system and device driver code.) Then define the little known
DEBUG DBG$IMAGE_DSF_PATH logical to point to the directory where the DSF
lives...I believe that the DSF must be the same name as the EXE and DMP, e.g.
TEST.EXE and TEST.DSF and TEST.DMP...they do NOT, however, need to be in the
same directory. That logical will tell debug to get the debug info from the
DSF instead of the EXE.
For example, I took your C example and called it 1867_4.C, compiled, linked
/NODEBUG, and generated a dump, analyzed the dump, generated a DSF, defined
the DBG$IMAGE_DSF_PATH logical, and reanalyzed the dump (BTW, the
DBG$DECW$DISPLAY logical simply forces the debugger into its character cell,
SMG, interface versus the Motif GUI):
$ ty 1867_4.c
#include <lib$routines.h>
main ()
{lib$signal(12);}
$
$
$ cc/debug/noopt 1867_4.c
$ link 1867_4
$ set proc/dump
$ run 1867_4
%SYSTEM-F-ACCVIO, access violation, reason mask=E4, virtual address=000000000000001B,
PC=0000000000010030, PS=7B0E839D
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
1867_4 1867_4 main 3924 00000000000000E4 00000000000200E4
1867_4 1867_4 __main 0 0000000000000090 0000000000020090
0 FFFFFFFF8207E914 FFFFFFFF8207E914
$
$
$ define dbg$decw$display " "
%DCL-I-SUPERSEDE, previous value of DBG$DECW$DISPLAY has been superseded
$ ana/proc 1867_4
Condition signalled to take dump:
%SYSTEM-F-ACCVIO, access violation, reason mask=E4, virtual address=000000000000001B,
PC=0000000000000003, PS=00002604
%DEBUG-I-SSINOTSET, system service interception is not setup, defaulting to nostatic
watchpoints
OpenVMS Alpha DEBUG Version V7.1-02R
predefined trace on activation at 1867_4\main\%LINE 3924+20 in %PROCESS_NUMBER 1
DBG_1> sho call
module name routine name line rel PC abs PC
*1867_4 3924 0000000000000000 00000000000200E4
*1867_4 __main 0000000000000090 0000000000020090
0000000000000000 FFFFFFFF8207E914
DBG_1> set radix hex
DBG_1> ex/source 00000000000200E4
module 1867_4
%DEBUG-W-SRCLINNOT, source lines not available for module 1867_4
DBG_1> exit
$
$
$ link/dsf 1867_4
$ dir/date/size/owner 1867_4
Directory REDSQL$:[HILDE.ADEBUG.DUMP]
1867_4.C;1 1 3-JUN-1997 14:30:31.25 [HILDE]
1867_4.DMP;1 368 3-JUN-1997 14:31:28.82 [HILDE]
1867_4.DSF;1 5 3-JUN-1997 14:38:55.41 [HILDE]
1867_4.EXE;2 5 3-JUN-1997 14:38:55.50 [HILDE]
1867_4.EXE;1 7 3-JUN-1997 14:31:18.16 [HILDE]
1867_4.OBJ;1 5 3-JUN-1997 14:30:55.77 [HILDE]
Total of 6 files, 391 blocks.
$
$ define dbg$image_dsf_path REDSQL$:[HILDE.ADEBUG.DUMP]
$
$ ana/proc 1867_4
Condition signalled to take dump:
%SYSTEM-F-ACCVIO, access violation, reason mask=E4, virtual address=000000000000001B,
PC=0000000000000003, PS=00002604
%DEBUG-I-SSINOTSET, system service interception is not setup, defaulting to nostatic
watchpoints
OpenVMS Alpha DEBUG Version V7.1-02R
predefined trace on activation at 1867_4\main\%LINE 3924+20 in %PROCESS_NUMBER 1
DBG_1> sho call
module name routine name line rel PC abs PC
*1867_4 3924 0000000000000000 00000000000200E4
*1867_4 __main 0000000000000090 0000000000020090
0000000000000000 FFFFFFFF8207E914
DBG_1> set radix hex
DBG_1> ex/source 00000000000200E4
module 1867_4
3924: {lib$signal(12);}
DBG_1> exit
$
Lon
| |||||
| 1867.2 | dbg$image_dsf_path feature started in V7.1 | SSPADE::SSPADE::HILDE | Tue Jun 03 1997 16:03 | 6 | |
That is, the dbg$image_dsf_path logical will not affect V7.0 and earlier debuggers. If similar problems exist there with ANALYZE/PROCESS_DUMP, then there is no known work around. Lon | |||||
| 1867.3 | Thanks! | GIDDAY::GILLINGS | a crucible of informative mistakes | Tue Jun 03 1997 23:14 | 7 |
Thanks Lon, that will be very useful. I'm pretty much convinced that the ACCVIO loop is H7.1 only. I'll have that system upgraded asap... Will /DSF become supported sometime? It looks like the answer to many requests for LINK/DEBUG/BUT_DONT_ACTIVATE_DEBUG_BY_DEFAULT_ON_A_RUN_COMMAND qualifier. John Gillings, Sydney CSC | |||||
| 1867.4 | SSPADE::SSPADE::HILDE | Wed Jun 04 1997 12:41 | 23 | ||
/DSF as a linker feature is supported today on ALPHA. Not sure when that became "official", V6.x I think. However, it's not planned to ever appear in VAX linkers. No reason it couldn't be put into VAX linkers...just not planned...and that's all that would need to change, I think. That is, I believe the DBG$IMAGE_DSF_PATH code in the debugger is NOT platform specific. Oddly, the use of the DBG$IMAGE_DSF_PATH logical is documented in the V7.1 linker manual under its /DSF qualifier documentation...BUT it is missing from the V7.1 Debugger Manual. This will be set right in the V7.2. You're right...using the /DSF switch alone, i.e. without the /DEBUG switch, will link an EXE and DSF. That EXE will RUN/NODEBUG by default and all the debug information will be in the DSF. Indeed products should consider doing exactly that and save the DSF for use later when (an if?) problems are reported from the field. With the DBG$IMAGE_DSF_PATH feature and the various optimized debugging features we support, they would then have the option of symbolically debugging their actual production images. Lon | |||||