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.

[Volker Halle]

Hein,

on Alpha, if you reach the 'memory limit' as imposed by the PHP.INI file, you get a nice error message. The default 'memory limit' seems to be around 8 MB (without a PHP.INI file).

If you specify an 'unreasonable' memory limit and actually try to reach that limit (by increasing the max. index value), the program 'silently' dies WITHOUT an error message, when remaining pagefile quota reaches 0.

Maybe it does not die so silently on OpenVMS I64 ?! Although you would need to be using a real small PGFLQUOTA to hit that limit with index = 160000.

Volker.

[Robert Atkinson]

Capturing quota info is a little difficult as the PHP script fails almost immediately.

For reference, here's the UAF quotas :-

Maxjobs: 0 Fillm: 150 Bytlm: 1000000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 150 JTquota: 4096
Prclm: 4 DIOlm: 4096 WSdef: 4096
Prio: 4 ASTlm: 4096 WSquo: 8192
Queprio: 0 TQElm: 10 WSextent: 16384
CPU: (none) Enqlm: 4000 Pgflquo: 5000000


I need to do some more investigation work on this, but I'm bogged down with some more pressing problems at the moment.

I guess I was looking for one of the quick wins that we sometimes get from the forums, and that one of you had come across this already.

As I'm still running PHP 1.3 (PHP 4.x), I really need to upgrade and test this again.

For the time being, I'll run the script under WAMP instead.

Rob.

[Volker Halle]

Rob,,

I've now installed CSWS_PHP V2.1 on OpenVMS I64 V8.2 and I cannot reproduce this problem. Without a PHP.INI file and by setting the index loop counter to 16000000, I get the same error message as with V1.3 ECO 2 on OpenVMS Alpha.

Your PGFLQUOTA looks a little bit ridiculous (2.56 GB).

Volker.

[Hein van den Heuvel]

Volker>> on Alpha, if you reach the 'memory limit' as imposed by the PHP.INI file, you get a nice error message.

That's my point.

>> If you specify an 'unreasonable' memory limit and actually try to reach that limit (by increasing the max. index value), the program 'silently' dies WITHOUT an error message

Well, I imagine where are flavors of mallocs going on. When simply allocating user data it may react different to failure then when allocating for some internal data structure.

Volker>> Although you would need to be using a real small PGFLQUOTA to hit that limit with index = 160000.

Yeah, for a simple fortran like array @ 4 bytes/integer with would be nothing. But this is probably implemented very dynamic/flexible with possibly a re-allocated element array and a malloc per element. So give is 32 bytes/object and it is still not much in total.


>> Capturing quota info is a little difficult as the PHP script fails almost immediately.

That's why you should focus on the SUCCESS cases, not the failures.
Of 20,000 is already too much, then try 8,000 and 16,000.
If 80K is too much then try 20k, 30K, 40K.

Rob>> For reference, here's the UAF quotas :-

Those looks like monkeys having thrown darts.
And they are likely to be overruled with SYSGEN PQL_M values.
FILLM is relatively low/scary.
TQ, WS settings low,
ASTLM/DIOLM high,
PGLFIL silly high.

Rob>> I guess I was looking for one of the quick wins that we sometimes get from the forums, and that one of you had come across this already.

Certainly. And Volker may have come through checking an other version.

Volker>> I've now installed CSWS_PHP V2.1 on OpenVMS I64 V8.2 and I cannot reproduce this problem.

Case closed! :-)

Volker>> Your PGFLQUOTA looks a little bit ridiculous (2.56 GB).

Ayup. Either clueless, or very smart (P2).

Grins,
Hein

[Robert Atkinson]

> Ayup. Either clueless, or very smart (P2).

Probably clueless :) but they're there because I tend to edit and convert large files > 2GB which tends to require larger PGFL sizes.

Rob.

[Volker Halle]

Rob,

playing with varying values of PGFLQUOTA and memory_limit, on OpenVMS I64 with CSWS_PHP V2.1, I now get a different error message:

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

Fatal error: Out of memory (allocated 872939520) (tried to allocate 1342
17728 bytes) in /dsa1/halle/itrc/rob.tmp on line 8

zend_mm_heap corrupted

memory_limit=1000M, PGFLQUOTA=2000000. One could assume, that your version of PHP V1.3 could have stumbled more severely in that situation...

Hein,

you seem to be right about the allocation per array element: ...(tried to allocate 35 bytes)...

Volker.