Process dump error meaning - BR R31,#X000228

[sathya prabu]

Hi,

While trying to debug a TDB file, there was an ACCVIO system error message. I got the process dump and analyzed it. I am getting the follwing the "things" that i could follow. Can anybody tell me what this means?

analyze/proc set.dmp

OpenVMS Alpha Debug64 Version V8.3-009


%DEBUG-I-NODSTS, no Debugger Symbol Table: no DSF file found and
-DEBUG-I-NODSTIMG, no symbols in DISK$ALPHASYS:[VMS$COMMON.SYSEXE]SET.EXE;1
%DEBUG-I-NOLOCALS, image does not contain local symbols
%DEBUG-I-NOGLOBALS, some or all global symbols not accessible
%SYSTEM-F-IMGDMP, dynamic image dump signal at PC=000000000004C8D4, PS=00000018
break on unhandled exception preceding SHARE$SET_DATA2+116948
DBG> exa/inst 313556
SHARE$SET_DATA2+116948: BR R31,#X000228
DBG> exa/inst 313555
SHARE$SET_DATA2+116947: BLBC R0,#X02286B
DBG> exa/inst 313554
SHARE$SET_DATA2+116946:
DBG> exa/inst 313553
SHARE$SET_DATA2+116945: LDBU R3,#X5A51(R11)
DBG> exa/inst 313552
SHARE$SET_DATA2+116944: JSR R26,(R26)
DBG> exa/inst 313551
SHARE$SET_DATA2+116943:
DBG> exa/inst 313550
SHARE$SET_DATA2+116942:
DBG>

[sathya prabu]

This was the actual ACCVIO msg while debugging!

Task is in SERVER SERVER_1
Task is in the task debugger
Task is in SERVER SERVER_2
%DEBUG-I-DYNMODSET, setting module INIT_1
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000140C9F3, PC=0000000000F6FD6C, PS=0000001B
break on unhandled exception at INIT_1\INIT_1\%LINE 305+16
305: Initialize INIT_1_WKSP.
DBG>

[Volker Halle]

Hi,

looks like the code intentionally created an image dump by signalling SS$_IMGDMP.

Try:

DBG> SET MODE HEX
DBG> EXA/INS 4C8D4-20:4C8D4

This should show you the instruction stream. The updated PC (probably after calling LIB$SIGNAL) points to the following instruction (0x04C8D4 = decimal 313556):

SHARE$SET_DATA2+116948: BR R31,#X000228

but you would be interested in the previous instructions...

Volker.

[Volker Halle]

So you're really trying to figure out the context of the ACCVIO. Try this:

DBG> SET MODE HEX
DBG> EXA/INS 0F6FD6C

Then look at the instruction opcode and figure out, which register contains a 'bad' or unexpected value. The access violation happened when trying to WRITE to virtual address 140C9F3

Volker.

[sathya prabu]

Hi,

I tried examining the instructions, but i got he follwing messages.

DBG> set rad hex
DBG> exa/inst 140C9F4
%DEBUG-E-NOACCESSR, no read access to address 000000000140C9F4
DBG> exa/inst 140C9F3
%DEBUG-E-NOACCESSR, no read access to address 000000000140C9F3
DBG> exa/inst 4C8D4-20:4C8D4
SHARE$SET_DATA2+1C8B4: LDQ R26,#XFF60(R2)
SHARE$SET_DATA2+1C8B8: ADDL R31,R9,R16
SHARE$SET_DATA2+1C8BC: BIS R31,R31,R17
SHARE$SET_DATA2+1C8C0: LDA R18,#X04FC(R31)
SHARE$SET_DATA2+1C8C4: BIS R31,#X03,R25
SHARE$SET_DATA2+1C8C8: LDQ R27,#XFF68(R2)
SHARE$SET_DATA2+1C8CC: LDQ_U R31,(SP)
SHARE$SET_DATA2+1C8D0: JSR R26,(R26)
SHARE$SET_DATA2+1C8D4: BR R31,#X000228

Please let me know what this says. I Hope i cannot read the address specified. Also, Every time i debug the TDB file, the debugger gives ACCVIO at either 140C9F3 or 140C9F4. Does this has anything to do with the QUOTAs? Also, i have tried setting the bytlm,wsextent and other memory limiting values higher, still i am getting the reason mask=04 ACCVIO. How should i approach this issue?

[sathya prabu]

Hi,

I got some more info..

The follwing is what i have got. There are no values in any adresses till 140C9ee. Please anybody let me know why the ACCVIO for that address happened during write operation and no values are in other addresses after 140C9ee? what should i do to prevent this?

DBG> set rad hex
DBG> exa/inst 140C9F3
ACM$SERVER_1+0A3:
DBG> exa/inst 140C9F2
ACM$SERVER_1+0A2:
DBG> exa/inst 140C9F1
ACM$SERVER_1+0A1:
DBG> exa/inst 140C9F0
ACM$SERVER_1+0A0:
DBG> exa/inst 140C9ef
ACM$SERVER_1+9F:
DBG> exa/inst 140C9ee
ACM$SERVER_1+9E: FBGE F11,#X006BFC

[Volker Halle]

The code at SHARE$SET_DATA2+1C8D0 is signalling SS$_IMGDMP by calling LIB$SIGNAL or LIB$STOP (most likely).

SHARE$SET_DATA2+1C8C0: LDA R18,#X04FC(R31)
loads 04FC into R18, this is the SS$_IMGDMP status code. You can verify this with $ EXIT %X4FC

I would assume, that this is code in some condition handler, which tries to force a process dump to enable the underlying exception to be diagnosed.

DBG> SHOW CALL

should show the call stack and the original exception (ACCVIO).

You need to concentrate on the ACCVIO. If EXAMINE of the failing virtual address also fails in the debugger (don't use EXA/INS, but just use EXA 140C9F3), you need to locate the failing instruction stream, as I said before:

DBG> EXA/INS 0F6FD6C-20;0F6FD6C

then decode the instruction shown at 0F6FDC and look at the register contents. Then figure out, why some register contains an invalid value pointing to a non-accessible virtual address.

Then find the source code for that instruction stream.

Volker.

[sathya prabu]

Hi Volker,

Thanks a lot for the help. I was able get more information on the issue.

Please just let me know what the below error means.

DBG> show call
module name routine name line rel PC abs PC
*INIT_1 INIT_1 305 000000000000031C 0000000000F6FD6C
SHARE$ACMTWPSHR 0000000000037BBC 0000000007CA5BBC
SHARE$ACMTWPSHR 0000000000039588 0000000007CA7588
SHARE$ACMTWPSHR 000000000003E08C 0000000007CAC08C
SHARE$ACMTWPSHR 000000000003DDCC 0000000007CABDCC
SHARE$ACMTWPSHR 000000000003A330 0000000007CA8330
SHARE$ACMTWPSHR 0000000000037DEC 0000000007CA5DEC
SHARE$ACMTWPSHR 00000000000393A0 0000000007CA73A0
*SERVER_1 ACM$SERVER_1 00000000000000D4 000000000140C9D4
SQL$PROC_2_A93A76_241CC1 0000000001927E18 0000000001937E18
----- the above looks like a null frame in the same scope as the frame below
0000000000079040 0000000000089040
FFFFFFFF80385D54 FFFFFFFF80385D54

DBG> set rad hex
DBG> exa SQL$PROC_2_A93A76_241CC1
RDB$SUBROUTINE_1_SR\SQL$PROC_2_A93A76_241CC1: 01403099

DBG> exa 1937E18
SQL$PROC_2_A93A76_241CC1+658: 23DE0010A79E0008
DBG> exa 1927E18
RDB$SUBROUTINE_2_SR\SQL$PROC_1_A8EB7D_9563C1\%LINE 309+18: LDL R18,#X00B0(R3)

DBG> exa SQL$PROC_1_A8EB7D_9563C1
RDB$SUBROUTINE_2_SR\SQL$PROC_1_A8EB7D_9563C1: 06803099


-sathya

[Volker Halle · Accepted solution]

Sathya,

this is getting confusing.

In the initial post, you've analyzed a process dump with a %SYSTEM-F-IMGDMP at PC=04C8D4.

In your last response, your SHOW CALLS output does not match this situation. It should have also listed SHARE$SET_DATA2+116948

Please ALWAYS use DBG> SET RADIX HEX, so that the addresses shown always are in hex.

The ACCVIO seems to have been reported at
*INIT_1 INIT_1 305 000000000000031C 0000000000F6FD6C

Now examine

DBG> SET MODE HEX
DBG> EXA/INS 0F6FD6C-20;0F6FD6C

Please note that the failing VA of 0140C9F3 is pretty close to the following return address on the stack:

*SERVER_1 ACM$SERVER_1 00000000000000D4 000000000140C9D4

Volker.

[sathya prabu]

Hi Volker,

Thanks a lot for your support

That was my mistake, the first time PC address was from a different code path and the second time PC address from a another call. But, both the times the write operation on the specific VA x140C9F0 + x0003 is failing.

I could get the exact place where the instruction failed.

Line 305: LDQ_U R24,#X0003(R3)
: LDQ_U R19,(R3)
: MSKLH R24,R3,R24
: MSKLL R19,R3,R19
-> : STQ_U R24,#X0003(R3)

In the entire routine, R3 is unmodified. From beginning it holds the same value in it. When STQ_U is tried on R24 with x0003(R3), the ACCVIO is thrown. Can you let me what kind of problem is this? how i can solve it? why R3 is holding the value when it knows it cannot write to address location it is holding?

The correspoding line was an INITIALIZE line in case of one SUBROUTINE.

In case of the other the corresponding line was a MOVE operation.

Thanks,
-Sathya