<snip>
-bash-2.05b$ php test.php Content-type: text/html X-Powered-By: PHP/4.3.10
Memory Limit: 32K Memory Used: 13432 Error (1024) in /www/l-i-e.com/web/test.php:12 - Test ....-bash-2.05b$
Note a complete lack of "Made it" nor an error message trapped by my error handler when the RAM runs out. :-(
This is the symptom I had when I recoded t osomething very similar.
Looks like the Memory limit is hard-coded and won't trigger an error handler nor will it give you any chance to catch it.
Yes, This might be a mis-discription of error, that this error really is php-fatal not just script-fatal.
<snip>
With error handling as normal, can it handle a fatal error? My issue is not it would not report a fatal error, it does not continue with the script.
I think maybe not -- but maybe only specific errors exhibit this feature.
Memory limit and Time limit could be "weird" enough to need it.
You could try some other fatal errors to see.
Some errors do seem to be caught correctly such as Parse Error - (especially with Eval) which highlights my theory of fatal being either script-fatal or program-fatal. if its the PHP application that has died, then it would explain why the memory limit and some others might not execute correctly. I did not try time, but suspect that would be script-fatal. Both these limits are designed to protect your computer from crashing becuase of bad programmers (/me looks guilty), and it would be daft to allow a programer to continue with code once either of these have been breached.
The last issue I am worried about is scope - if I have run out of memory, then what can I do - I seem to have issues running commands which go over this limit during the command (irrelevant of their end memory usage). Supposing I had enough memory to run the set_ini function and increase my memory limit, then I would be able to execute any command to roll back (transaction wise) the program execution so far, and email/notify/whatever. This is irellevant if a "success" orientated monitoring method is implemented.
I think you would be well-served to figure out where the RAM is going, and making sure it's what it should be at various junctures.
yes, I seem to have a memory leak, which has been explained to me by a collegue as a possibility that I am including a new object line inside the loop (being used to Java's garbidge collector (and my manual calling of it)) that would get recreated each loop, without much impact on memory, and that removing the new call to outside the loop, and placing a "refresh" or "renew" function into my object would save me memory.
This is a little concern as this is difficult to find in the code - the only "large" (proportional to avail-mem) objects that Im using are in loops of ten to twenty seconds (due to database calls).
Maybe you're trying to patch symptoms instead of debugging the true problem.
Just a thought.
Of course, an efficient elegant working program is always to be desired, but the nature of this problem is potentially a PEBCAK - I can not always limit the input ranges suitably (due to number of combinations of different variables), perhaps I should write a calculate function which takes the same arguments as the real function, and guesses to its length of time to run and its memory usage. That way I can make a descision as to whether to run it or not (of course it would take me a while to get the memory profile accurate, but would be nice to see). This isnt as easy as just saying if $x < 10 and $y < 10 or max $x must be inversly proportional to $y (so as $y increases the max $x can be must decrease) as it would involve actual data in the database and knowing how different data affects the speed / memory. But thats my problem and very specific to whats going on, so feel free to ignore...
You could also maybe file this as a bug, after searching the bugs database to see if it's a known issue, or even a "feature"
I dont think it is a bug I think it makes sense in its repeats, but I think I'll add a comment to the page on the php manual with my findings, and link to this discussion.
Thanks for that
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
