ACCVIO, access violation, reason mask='xx', virtual

[Malleka Ramachandran]

I have a question regarding the ACCVIO error, particularly about the second part:
"This message is also displayed when an attempt has been made to make the user stack larger than the user's virtual address space permits. For example, the automatic user stack expansion algorithm reports an access violation with the following two conditions (which should serve as hints that automatic
expansion has failed):
The reason mask has the low-order bit set. This indicates a
memory reference that is not described in any page table.

o The relatively small P1 address space virtual address is referenced.

I would like to know what exactly the "The relatively small P1 address space virtual address" means.
I have a dump with an ACCVIO error and the PC does not point to a valid location within the application. Also this seems to have reoccurred about a month later, so I am trying to find out if the message is due to the user stack getting bigger as mentioned above. The first part of this is not true either, the reason mask is 00, so what should I be looking for in the virtual address diaplayed to determine if this is the case?

Thanks,
Malleka

[Steven Schweda]

For an explanation of the address space(s),
see, for example:

http://h71000.www7.hp.com/doc/82FINAL/5841/5841PRO.HTML

http://h71000.www7.hp.com/doc/82FINAL/5841/5841pro_035.html

As usual, it might help if you provided the
actual error message so that someone else
could see what you see, like, for example,
the actual virtual address.

If "the reason mask is 00", why are you
worrying about possible explanations of
what's wrong when the reason mask is _not_
00?

[Volker Halle · Accepted solution]

Malleka,

please show us the real ACCVIO message as printed after ANAL/PROC imagename.DMP

A reason mask of 00 indicates, that an attempted read access failed. The virtual address value would be most interesting as well as the PC.

If the PC value does not point to a valid address in the application, it could either be pointing to system space (address 8xxxxxxx) or could be invalid itself, which would be confirmed, if it's value is about the same as the failing virtual address.

P1 space ranges from 4000000 to 7FFFFFFF and 'expands' towards decreasing addresses. So a 'relatively small' P1 space address would be a value towards the lower address limit.

Volker.

[Steven Schweda]

> So a 'relatively small' P1 space address
> would be a value towards the lower address
> limit.

Yes, but what it said was a value in the
"relatively small P1 address space", not a
small address. The point was that the whole
P1 address space is small, compared to, say,
P2.

[Volker Halle]

Steven,

the HELP/MESS ACCVIO help text comes from the days of OpenVMS VAX, where there was no P2 space at all. P1 space is the same size as P0 space, so maybe the message should really say:

o A relatively small P1 address space virtual address is referenced

Volker.

[Guenther Froehlin]

I doubt this has anything to do with the user stack in P1 space. According to this http://h71000.www7.hp.com/doc/82FINAL/5841/5841pro_027.html#bottom_027 a reason mask of 0 means a failed read access due to page protection. The virtual address (VA) listed in the ACCVIO message should give and idea why this page is protected (e.g. '00000000', or '8xxxxxxx'). This is pretty much a program bug. If a certain type and handled poorly in the program (e.g. LIB$GET_VM) an increase of the process PGFLQUOTA might help (for a while).

[Malleka Ramachandran]

This is the accvio message I get:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000000000CD, PC=0000000000108FA8, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
00000000000000CD
0000000000108FA8
000000000000001B

Register dump:
R0 = 00000000000000CD R1 = 00000000000000CD R2 = 000000000001B708
R3 = 0000000000030000 R4 = 000000007ADF49A9 R5 = 0000000000000000
R6 = 0000000000000001 R7 = 0000000000000001 R8 = 000000007FF9CDE8
R9 = 000000007FF9DDF0 R10 = 000000007FFA4F30 R11 = 000000007FFCDBE0
R12 = 000000007FFCDA60 R13 = FFFFFFFFB7360B70 R14 = FFFFFFFF8343E900
R15 = 0000000000064838 R16 = 000000007ADF4930 R17 = 00000000000000CD
R18 = 000000007ADF4930 R19 = FFFFFF0030323533 R20 = 0000000000000030
R21 = 000000007ADF494B R22 = 000000007ADF4920 R23 = 000000007ADF4860
R24 = 000000007ADF4879 R25 = 0000000000000002 R26 = 00000000000E02EC
R27 = 000000000001F6E0 R28 = 0000000000024E98 R29 = 000000000001F6E0
SP = 000000007ADF4910 PC = 0000000000108FA8 PS = 100000000000001B


I think I was not using the correct procedure to decode the address. I tried to locate the range of addresses in the map file corresponding to the PC but now I read in the FAQ that the range corresponding to the virtual address should be used and the offset for the PC should be located in the list file. I was doing the reverse.

According to the FAQ, this is what I see in the map file, closest to the virtual address.
So does it mean that the arguments passed to LIB$SET_LOGICAL could be causing the access violation to occur?

LIB$SET_LOGICAL 000000C0-RX LIBRTL

[Hein van den Heuvel]

>> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000000000CD, PC=0000000000108FA8, PS=0000001B

Ah, good, some details.
This looks like a pretty basic programming bug at first glance.


>> So does it mean that the arguments passed to LIB$SET_LOGICAL could be causing the access violation to occur?
>> LIB$SET_LOGICAL 000000C0-RX LIBRTL

NO. That's just a relocatable address, not fully resolved.

That 00000000000000CD is probably simply used as data address, and thus invalid (first data tends to start at 0x10000)
A not unikely reason for this is that CD is in fact the OFFSET (205) in a structure for which the pointer accidently was 0.

Did this code ever work?
Waht changes recently?
Can you run and reproduce with the debugger?
Just DBG> SET BRE /EXCEP .. GO

>> PC=0000000000108FA8,

That you can look up in the MAP and work your way back to an offset in a module.
But the debugger would be much easier

hth,
Hein.

[Volker Halle]

Malleka,

if you look at the registers at the time of the ACCVIO, you'll find that R0, R1 and R17 contain the failing VA = 000000CD

R17 normally contains the address/value of the 2nd parameter passed in a call. If we assume, that the ACCVIO happens after some routine has been called, it's pretty obvious that the 2nd parameter passed in that call contained a bad value. The calling routine may then have copied that value to R0/R1 and used any of those 3 register as a memory address in a memory read reference thus causing the access violation.

If you can run the program with the debugger, follow the advice given by Hein (DBG> SET BREAK/EXCEP).

Your problem description seem to imply, that this problem only occurs after an extended run-time (a month or so) and that you have a process dump available to you.

Which version of OpenVMS (V7.3 or higher) ?

If you have a MAP available, look for a module including the failing PC address: 000108FA8

Also try this:

$ ANAL/PROC process_dumpfile.dmp
DBG> SET RADIX HEX
DBG> SHOW CALL
DBG> EXA/INS @PC
DBG> EXA/INS 0E02EC ! look at RETURN ADDRESS

On OpenVMS V7.3 or higher try this:

DBG> SDA
SDA> SHOW PROC/IMAGE
SDA> EXIT
DBG> EXIT

This will show you the VA range of all activated images inside the process.

Volker.