CSWS PHP 1.3 (PHP Version 4.3.10) %SYSTEM-F-HPARITH

[Mark Daniel_2]

Also, and I'm never sure if you guys want to hear about this sort of stuff, I consistently get the following from deep down in the sharable image (unfortunately it's a non-trivial PHP application - phpMyAdmin), way out of my depth. The rest of the PHP application, and others, works quite well. Don't think it's my fault. Might help you pinpoint an obscure issue.

OpenVMS Alpha V8.2
CPQ-AXPVMS-CSWS_PHP-V0103--1.PCSI

> %SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00000002, summary=02, PC=00000000001E9C94, PS=0000001B
> -SYSTEM-F-FLTINV, floating invalid operation, PC=00000000001E9C94, PS=0000001B
> %TRACE-F-TRACEBACK, symbolic stack dump follows
> image module routine line rel PC abs PC
> PHPSHR 0 0000000000197C94 00000000001E9C94
> PHPSHR 0 000000000015E1AC 00000000001B01AC
> PHPSHR 0 0000000000164F94 00000000001B6F94
> PHPSHR 0 00000000001635F4 00000000001B55F4
> PHPSHR 0 000000000016417C 00000000001B617C
> PHPSHR 0 0000000000185088 00000000001D7088
> PHPSHR 0 0000000000187C24 00000000001D9C24
> PHPSHR 0 0000000000187C24 00000000001D9C24
> PHPSHR 0 0000000000174BB8 00000000001C6BB8
> PHPSHR 0 0000000000142D54 0000000000194D54
> PHPWASD PHPWASD ProcessRequest 43135 0000000000001BEC 0000000000031BEC
> PHPWASD PHPWASD main 42757 00000000000005A8 00000000000305A8
> PHPWASD PHPWASD __main 0 000000000000006C 000000000003006C
> 0 FFFFFFFF80325F94 FFFFFFFF80325F94

(FWIW I hate the interface to this forum with a passion which is perhaps a contributing reason not to use it more.)

[Willem Grooters]

Looks familiar, though using Apache on VMS 7.3-2. I had the same with a plain php application and I was told that there are some issues with this version of PHP.
It mighht (should) be solved with the new vertsion but you will need to install SWS 2.1 (just out)

[Mark Daniel_2]

This is the latest version of CSWS PHP Willem (V1.3), released Nov 18th along with HP SWS 2.1, CSWS Perl 2.1, et al. So it's not likely to be fixed in that release ;-)

[John Gillings]

Mark,

Please log a case so I can look into this deeper. Hearing your name associated with an(other) HPARITH is a bit of a concern... ;-)

Chances are it's an uninitialised variable. We should be able to track it down.

[Mark Daniel_2]

Hey John, you're right. I'd almost forgotten my fifteen minutes of (in)fame(y) (so-to-speak). I also forget that even open-source can come under a support contract. I'll do that in the morning (providing we still have one ;-)

[John Gillings]

For anyone who's interested...

We have a case logged with HP for this issue. It appears to be an uninitialised floating point variable.

From the message:

>Imask=00000000, Fmask=00000002, summary=02


FMASK indicates register F1, summary indicates an illegal operand. Tracking it down to actual code in PHPSHR it harder, as we don't have access to link maps. However, since the source is available, it should be possible to build a version of PHPSHR with traceback and a full link map.

Code stream looks like this:

PHPSHR+00197C58: SLL R11,#X14,R11
PHPSHR+00197C5C: ADDL R18,R11,R11
PHPSHR+00197C60: STL R11,#X006C(FP)
PHPSHR+00197C64: LDG F1,#X0060(FP)
PHPSHR+00197C68: LDG F10,#X0068(FP)
PHPSHR+00197C6C: LDL R22,#X002C(FP)
PHPSHR+00197C70: LDL R23,#X0028(FP)
PHPSHR+00197C74: CMPULT R31,R15,R15
PHPSHR+00197C78: CPYS F7,F7,F12
PHPSHR+00197C7C: CPYS F7,F7,F13
PHPSHR+00197C80: DIVG F1,F10,F1
PHPSHR+00197C84: AND R22,R4,R26
PHPSHR+00197C88: BIS R23,R26,R26
PHPSHR+00197C8C: XOR R23,#X01,R23
PHPSHR+00197C90: BIS R23,R22,R22
PHPSHR+00197C94: CMPGLE F1,F8,F11
PHPSHR+00197C98: FBEQ F11,#X000015

The fault PC is the CMPGLE, but I think it's more likely to be the DIVG a few instructions higher (the trap shadow for a DIVG is *many* instructions)

The LDGs higher up look like they might be coming from a homed argument list.

[Mark Daniel_2]

Thanks to John (and a maintenance contract - just hanging in there) we have some possibilities for further investigation. As this will need to happen in my own time it may not be for a few days (perhaps next weekend). I'll not close this thread until we have something definite or (I) have given up.

I should have added that PHPSHR behaves this way regardless of whether it's being used from within CSWS V2.1 or WASD's own PHP enrionment (which uses the CSWS PHPSHR). It was just easier (for me) to get a traceback via WASD. I only know how to check the error_log for fingerprints of such misdemeanours in Apache children.