PHP Array Causing Access Violation

[Robert Atkinson]

This simple script is causing the Access Violation below :-

$array1 = array();
$value1 = 1;

for ($index = 0; $index < 160000; $index++) {
$array1[] = $value1;
}

?>


Memory Limit in PHP.INI is set to 1000M. If I set the loop count lower, it's fine.

Any ideas?

Rob.




ALPHA_RAA$$ php rob.tmp
Content-type: text/html
X-Powered-By: PHP/4.3.10

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000000000, PC=0000000000254A50, PS=0000001B

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

Register dump:
R0 = 0000000000000000 R1 = 00000000006DE000 R2 = 000000007AAD7DF0
R3 = 0000000000000004 R4 = 000000007FFCF818 R5 = 000000007FFCF8B0
R6 = 0000000013F2AF01 R7 = 0000000000000001 R8 = 0000000000000000
R9 = 0067000000000000 R10 = 00000000009777C0 R11 = 0000000000002E08
SP = 000000007AAD7DF0 TP = 000000007B4E81C8 R14 = 0000000000000000
R15 = 000000007AAD7DE0 R16 = FFFFFFFF820851A0 R17 = 0000000000002E18
R18 = 000000000097C3F0 R19 = 000000000008B874 R20 = 0000000000970760
R21 = FFFFFFFFFFFFFFBE R22 = 0000000000000000 R23 = 0067000000970760
R24 = 00000000009777F0 R25 = 0000000000000001 R26 = 000000000008D0F8
R27 = 000000000096D610 R28 = 0000000000000000 R29 = FFFFFFFFFFFFFFE7
R30 = 000000000008CFD0 R31 = 000000007AAD7BE0 PC = 0000000000254A50
BSP/STORE = 000007FDBFFD4310 / 000007FDBFFD42A8 PSR = 0000101308426030
IIPA = 0000000000254A40
B0 = 0000000000254AB0 B6 = FFFFFFFF820851A0 B7 = FFFFFFFF80128550

Interrupted Frame RSE Backing Store, Size = 12 registers

R32 = 0000000000089498 R33 = 000000000000001D R34 = 0000000000088C30
R35 = 000000000008B83C R36 = 0000000000000002 R37 = 0000000000000800
R38 = 0000000000088C30 R39 = 0000000000000019 R40 = 00000000001E3E10
R41 = C000000000000692 R42 = 00000000006DE000 R43 = 00000000009777C0
ALPHA_RAA$$

[Volker Halle]

Rob,

the code is trying to write to virtual address ZERO, this fails with an ACCVIO.

Try SET PROC/DUMP before running your PHP test script and then have a look at the process dump with ANAL/PROC xxx.DMP

Volker.

[Jan van den Ende]

Rob,

>>>
If I set the loop count lower, it's fine.
<<<

As in,
$index < 159999
or just much lower?

In other words, have you determined what the exact limit is?

Proost.

Have one on me.

jpe

[Robert Atkinson]

I knocked a zero off and it worked OK.

[Robert Atkinson]

ALPHA_RAA$$$ anal/proc php.dmp

OpenVMS I64 Debug64 Version X8.3-015


%DEBUG-W-IMAGENF, target image PHP not found on host system
%DEBUG-W-IMAGENF, target image PHP_MYSQL not found on host system
%DEBUG-W-IMAGENF, target image PHP_OPENVMS not found on host system
%DEBUG-W-IMAGENF, target image PHP_PCRE not found on host system
%DEBUG-W-IMAGENF, target image PHP_SESSION not found on host system
%DEBUG-W-IMAGENF, target image PHP_SOCKETS not found on host system
%DEBUG-W-IMAGENF, target image PHP_XML not found on host system
%DEBUG-W-IMAGENF, target image PHP_ZIP not found on host system
%DEBUG-W-IMAGENF, target image PHP_ZLIB not found on host system
%DEBUG-I-TRUNC64, address 0000005000020460 being truncated in RSTCNTRL\DBG$DST_RST_BUILD
%DEBUG-I-CRMPSCFAIL, failed to map-in the Debugger Symbol Table (DST)
-DEBUG-E-BADSTATUS, bad status returned from SYS$CRMPSC
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%DEBUG-I-CRMPSCFAIL, failed to map-in the Debugger Symbol Table (DST)
-DEBUG-E-BADSTATUS, bad status returned from SYS$CRMPSC
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%DEBUG-I-NOUNIVERSALS, shareable image contains no universal symbols
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000000000, PC=0000000000254A50, PS=0000001B
%DEBUG-I-ERRINSDEC, error decoding instruction at current PC
%DEBUG-E-INTERR, debugger error in RSTACCESS\DBG$STA_VALSPEC - Dwarf AND DST or session corruption
break on unhandled exception at
DBG> Exit

[Volker Halle]

Rob,

your test script runs fine on OpenVMS Alpha V8.3 with CSWS_PHP V1.3 installed:

CHARON-AXP $ php rob.tmp
Content-type: text/html
X-Powered-By: PHP/4.3.10

CHARON-AXP $

If I add another '0' to the loop index, it fails with a meaningful error message:

CHARON-AXP $ php rob.tmp ! with $index < 1600000
Content-type: text/html
X-Powered-By: PHP/4.3.10



Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /sys$sysroot/sysmgr/rob.tmp on line 6



So I'd say this is a bug in your PHP version.

Volker.

[Volker Halle]

Rob,

it appears that you need to add an /IMAGE_PATH= qualifier to ANAL/PROC and point it to the directory containing the PHP*.EXE files. Also you seem to need more privs for that debug session.

Once you're at the DBG> prompt, try:

DBG> EXA/INS @PC
DBG> SHOW CALLS

Volker.

[Robert Atkinson]

I have all privs switched on.

ALPHA_RAA$$$ anal/proc/image_path=phppath php.dmp

OpenVMS I64 Debug64 Version X8.3-015


%DEBUG-I-NODSTS, no Debugger Symbol Table: no DSF file found and
-DEBUG-I-NODSTIMG, no symbols in DISK$ORACLE:[APACHE.PHP.BIN]PHP.EXE;1
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000000000, PC=0000000000254A50, PS=0000001B
break on unhandled exception at SHARE$PHPSHR_CODE2+1862224
DBG> EXA/INS @PC
SHARE$PHPSHR_CODE2+1862224: st4 [r22] = r20
DBG> SHOW CALLS
module name routine name line rel PC abs PC
SHARE$PHPSHR_CODE2 00000000001C6A50 0000000000254A50
SHARE$PHPSHR_CODE2 0000000000155E10 00000000001E3E10
0000000000002950 0000000000022950
0000000000000E30 0000000000020E30
DBG>

[Volker Halle]

Rob,

the failing instruction is in the PHPSHR.EXE image. If you would do DBG> EXA R22 it should report a value of 0 - that's causing the ACCVIO.

The next step would be to try to find out, how R22 has been loaded with this invalid address. But as you probably don't have the PHP sources, it would be a tedious excercise.

Which version of PHP are you running ? Did you install any update kits ? DIR SYS$HELP:*PHP*.REL*

Volker.

[Hein van den Heuvel]

The Occam's razor mechanism suggests that the process ran out of addressable memory.

Proof 1:
If I set the loop count lower, it's fine.
Use more: kaboom, Use less: ok.
Proof 2:
Memory Limit in PHP.INI is set to 1000M.
You lied to the system and you expect it to behave reasonably?

The absolute maximum addressable memory is 1024M (give or take a page). Your process needs a fair amount MB's to place the code, and other variables.
So you _may_ have 900M available to begin with.
Just check a near idle session with F$GETJPI(pid,"FREP0VA")

But you know the the pages you can dirty are further constraint by PGFLQUOTA.
Check PAGFILCNT, for an idle sessione while you are at it.

Now Jan raises a fine question.
How much less works?

You respond 10x less. Fine (ish)
So try 20,000 - 40,000 and 80,000
For each record and report: FREP0VA and PAGFILCNT
Maybe that suggests a limit?
I honestly do not know.
Just suggesting an analytic approach.

You may also want to use:
$ SHOW PROC/CONT xxx ! Hit "q" for QUOTA page.

Hope this helps,
Hein.