Re: PHP Array Causing Access Violation

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,000For each record and report: FREP0VA and PAGFILCNTMaybe 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.

Re: PHP Array Causing Access Violation

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.

Re: PHP Array Causing Access Violation

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.

Re: PHP Array Causing Access Violation

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.