Conference vaxaxp::vmsnotes

640.0. "ANALYZE/PROCESS/IMAGE= => VA_IN_USE Alpha V7.1" by GIDDAY::GILLINGS (a crucible of informative mistakes) Sun May 25 1997 21: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

   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