accvio on an fopen

[labadie_1]

A big C program does an accvio on a fopen.
I added a print of perror, but it still accvios before.

any idea why, on an fopen of a file disk:a'x.dat
with x varying.
I get the accvio

The .dir is 1 block only, and this (of course) happens once a day, when numerous files are created without problem.

the accvio

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000228000, PC=FFFFFFFF8083008C, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
0 FFFFFFFF8083008C FFFFFFFF8083008C
0 FFFFFFFF809D73A0 FFFFFFFF809D73A0
0 FFFFFFFF809AD6F4 FFFFFFFF809AD6F4
0 FFFFFFFF80A84BC0 FFFFFFFF80A84BC0
0 FFFFFFFF80A86AB0 FFFFFFFF80A86AB0
0 FFFFFFFF80996698 FFFFFFFF80996698
0 FFFFFFFF809AA40C FFFFFFFF809AA40C
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000028, PC=000000007B9281DC, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
0000000000000028
000000007B9281DC
000000000000001B

Register dump:
R0 = 0000000000158264 R1 = 0000000000000001 R2 = 000000007B916520
R3 = 000000007AE1E8E8 R4 = 000000007AE1E890 R5 = 000000007AE1E878
R6 = 000000007AE1E898 R7 = 000000007AE1E888 R8 = 000000007AE1E880
R9 = 00000000001FB6F0 R10 = 0000000000000000 R11 = 0000000000000006
R12 = 0000000000000000 R13 = FFFFFFFF8111DE10 R14 = 000000007BFA2118
R15 = 000000007BFA211C R16 = 0000000000158264 R17 = 0000000000000000
R18 = 0000000000000000 R19 = 0000000000000000 R20 = 0000000000000000
R21 = 0000000000000001 R22 = 0000000000000000 R23 = 00000000001E8040
R24 = 0000000000000000 R25 = 0000000000000020 R26 = 000000007B928194
R27 = 00000000001E8040 R28 = 000000007AE1E630 R29 = 000000007AE1E630
SP = 000000007AE1E630 PC = 000000007B9281DC PS = 300000000000001B
DUPONT job terminated at 8-JUL-2004 12:46:59.99

[Antoniov.]

Hi,
may be access trouble (for example on process is writing sequential file with deferred write and another file try to read or write on same).
Also may be file is a device and user have not privilege to open device.

Antonio Vigliotti

[Uwe Zessin]

Antonio,
SS$_ACCVIO usually indicates an invalid access to memory like trying to write to readonly-cell or trying to read from an address where no memory is mapped.

'reason mask=04' indicated the type of access. If I recall correctly, it means a write attempt.

I don't think the traceback does help much, but it's been a long time since I did debugging on OpenVMS - I suggest you try to generate a process dump next time so you can do a post-mortem analysis.

[labadie_1]

this process does always the same thing: creates a new file disk:a'x.dat

I have now a process dump, the program has C code and C++;

I wonder why this "write attempt" fails, all the files are created in the same directory, have a similar name...

May be I should add an exception handler.

[Craig A Berry]

Hmm. The value of R0 in the register dump sometimes has a more precise (or prior) condition.

$ exit %x158264
%LIB-F-BADBLOADR, bad block address

From help/message:


BADBLOADR, bad block address

Facility: LIB, Library Facility

Explanation: Either the LIB$FREE_VM or LIB$GET_VM library routine is called
with an invalid virtual storage address.

User Action: Begin debugging procedures to verify and correct the problem.
----

which doesn't really tell you much you didn't already know.

The easiest way to debug this would be to build a debug version and let it run until you exercise the bug. Then you could examine the exact arguments to fopen. I assume you have already built a linker map and that's how you know you are in fopen when the accvio occurs.

Since the code is apparently something that runs for a long time, a memory leak of some kind would be a prime candidate, as would anything that triggers a clean-up or garbage collection operation and accidentally frees something that is still in use.

[Hein van den Heuvel]

Accvio normally has nothing to do with (rms) file IO, even if it seems to happen during an IO statement. General (malloced) memory corruption is much more typical. In it's most simple case the filename parameter woudl be bogus, but I don't think that is the case here. Still, I do nto really understand what you mean with the filename syntax presented. And just in case you might want to stick the name in a variable which you first use for a printout 'about to open xxx', and then for the fopen without further modification.

For now forget about looking for interaction with directory size, or deferred write or anything along those lines.

>>> I wonder why this "write attempt" fails, all the files are created in the same directory, have a similar name...

Like I said, do NOT associate ACCVIO (writing to memory) with writing to files. They have nothing to do with each other.

>>> process is writing sequential file with deferred write and another file try to read or write on same

That would be a serious RMS bug. No way. That stuff works. Period.

>>> Also may be file is a device and user have not privilege to open device.

That would be a serious error handling bug in c-rtl or program. No way.


craif>>>The value of R0 in the register dump sometimes has a more precise (or prior) condition.
$ exit %x158264
%LIB-F-BADBLOADR, bad block address

Right. And what makes this more likely is that when you corrupt memory in really bad places, it is well possible to throw bith debugger and rtl exception handlers way of course making it very hard to debug.

I'm afraid this may be a tough one to find...

Hein.

[John Gillings]

Gerard,

The ACCVIO and the probable BADBLOADR together strongly suggest your program is corrupting heap memory. That's very easy to do in C. The fopen is more than likely a victim, rather than the culprit.

You could try running the program under the heap analyzer, or, put some test code in strategic places. Write yourself a little routine "heap_check". Use LIB$FIND_VM_ZONE in a loop to find all the heap zones in use. For each one call LIB$VERIFY_VM_ZONE to make sure it's OK. If all is well just return. If not, generate some message or log entry.

You then know that the corruption has occurred between the last good call to heap_check and the current one. From there, binary search the code to home in on the bug.

[labadie_1]

thanks to all

yes I am now convinced that the fopen is just a victim.

the filename is disk:a2349.dat, with 2349 varying.

[labadie_1]

With the article

[OpenVMS] Example C - How to Build a C File From C Heap Routine Traces

http://h18000.www1.hp.com/support/asktima/operating_systems/009D5576-DEA17C80-1C0186.html

I think it will be easy to find the bug.

Many thanks to the author of the article.