SWS 2.1 + PHP w/ MyUPB ACCVIO

[Aaron Sakovich]

I'm running SWS v2.1 on Alpha 7.3-2 with PHP 1.3. I've been playing with a forum package, MyUPB, and have been getting ACCVIOs.

The package is available at: http://www.myupb.com/ourscripts_upb.php

The ACCVIO in my Apache$SWS*.LOG file looks like the following:

$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=0000000000000000, PS=0000001B

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

Register dump:
R0 = 000000000000001C R1 = 000000000000001D R2 = 0000000000000000
R3 = 0000000000000000 R4 = 0000000000000000 R5 = 0000000000000000
R6 = 0000000000000000 R7 = 0000000000000000 R8 = 0000000000000009
R9 = 00000000010912E0 R10 = 0000000000000006 R11 = 0000000001050000
R12 = 0000000000000000 R13 = 0000000000C0ADE8 R14 = 0000000000C0B1AC
R15 = 0000000000C0B1A8 R16 = 000000007AEA8748 R17 = 0000000000000000
R18 = 0000000000000003 R19 = 0000000000000001 R20 = 000000007FFF0000
R21 = 0000000000000002 R22 = 0000000000000000 R23 = 0000000000000000
R24 = 0000000037DF94F9 R25 = FFFFFFFF817548C0 R26 = 0000000000000000
R27 = 0000000000000004 R28 = 0000000000000000 R29 = 0000000000000000
SP = 000000007AEA8780 PC = 0000000000000000 PS = 000000000000001B
APACHE$WWW job terminated at 11-MAR-2006 22:24:32.22

Accounting information:
Buffered I/O count: 2754 Peak working set size: 19056
Direct I/O count: 477 Peak virtual size: 438912
Page faults: 1228 Mounted volumes: 0
Charged CPU time: 0 00:00:07.22 Elapsed time: 0 00:12:46.89

I've checked all the account quotas and they look per spec as documented.

Anxious for ideas,
Aaron

[Volker Halle]

Aaron,

to collect more information about this, consider to enable a process dump:

$ SET PROC/DUMP ! in LOGIN.COM for APACHE$WWW

You will then get a process dump file written to - by default - the login directory as imagename.DMP.

You can have a look at the process dump with ANAL/PROC imagename.DMP

The access violation happens, because the PC value is bad (PC=0), the reason mask =10000 indicates an ACCVIO during instruction fetch.

Volker.

[Volker Halle · Accepted solution]

Aaron,

this ACCVIO footprint looks surprisingly similar to your previous ACCVIO posted in:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=837732

Is it still the same problem ?

If you are interested in analyzing this problem (whether you do it yourself or try to get HP do it), a process dump is undoubtedly required.

As a first step, I would try to look at the stack for call frames and return addresses. You can also look at the process dump with SDA to find currently opened files and loaded images to try to narrow down which operation causes this ACCVIO.

There are not that many registers pointing to what may be instruction stream or data in P0 space. Try to have a look with SDA> EXA/INS addr-20;30

Volker.

[Volker Halle]

Aaron,

as both R26 and FP are zero, chances a very high, that the stack has been overwritten and the ACCVIO happens after restoring both FP (=R29) and RA (=R26) from the call frame and then trying to return with an RET R31,(R26) (or similar).

Volker.

[Aaron Sakovich]

Interesting thought. This is a completely different package, and I'm also running v2.1 of the SWS.

I do have several empty files out there, and one of the workarounds that helped with prior accvios was to make those files non-zero. I'll try that and get back with you.

You'd think PHP could handle a zero-length file without throwing a fit...

Thanks,
Aaron

[Aaron Sakovich]

That was it! It only took me a few seconds to nail that one -- it was indeed the zero length files that PHP was choking on.

I just did a:

$ pipe dir [...]/sel=size=max=0/nohead/notrail | eachline file "copy 1char.txt 'file' /replace"

and it cleared up the problem! Oh, 1char.txt is a file with a single space in it, and eachline.com is a procedure from dcl.openvms.org. (shameless plug)

Awesome! Sometimes you can't see the forest for the trees, and my brain cells are certainly fading with age... Or beer... I forget...

Thanks! BTW, that forum software seems to be working just fine on VMS -- the big bene is no DB required, it's all flat files! And it's fast!

Aaron

[Volker Halle]

Aaron,

now that we have identified the source of the problem and you've even found a simple workaround, wouldn't it be nice to let HP know about the problem ? Together with a process dump (you are in an easy position to supply one), this problem should be easily fixable.

If you can log a call with HP, please try to do so. The symptoms have now been 'publicly' documented and someone who knows how to research for 'APACHE$WWW ACCVIO' can find this, but people using Apache and PHP may not always be experienced enough to diagnose these kinds of problems.

Thanks,

Volker.

[Rick Retterer]

Aaron,
Could this be the very same problem with the CRTL and mmap? Sure seems like it to me especially after hearing that you worked around the problem by adding something to the zero length files.

This problem has been addressed and a patch generated for the problem, for the DECCSHR732 libraries.

Cheers,
Rick Retterer
HP Services.
Java Support.

[Rick Retterer]

Aaron,
I still have the patch available for you to download if you still need it. Otherwise, this fix will be included in the next release of the CRTL ECO.

Mike Boucher (C engineering) discovered a bug in the CRTL's mmap() function that we believe is the cause of the problem described in this case.

Cheers,
Rick

[Aaron Sakovich]

Rick,

Indeed it could -- do you know the specific ECO that needs to be applied to fix this? I'd be more than happy to look into updating it, especially if I can do it without a reboot.

Regards,
Aaron