Posted by James Taylor on 02/09/05 19:13

Richard Lynch wrote:
> James Taylor wrote:
>
> So finally quit that music thing and got a real job? :-)
>
> [Sorry. I'm sure you've heard them all, but I couldn't resist...]
>

/me adds Richard Lynch onto the list of those who must die when the
revolution comes...

>> I have a set of functions which are potentially dangerous in terms of
>>memory hogging, and need to protect from memory overflow - this is I
>>want to detect when the memory overflow occurs.
>>
>>The manual says that eval() will return false on a fatal error,

<snip snip>

>
> You may or may not have some success by preceding the eval with a @ and/or
> using http://php.net/error_reporting and/or using
> http://php.net/set_error_handler to trap the error.
>

Ok, using the @ that would get rid of the error message agreed, but it
still crashes the script (as a fatal error would and should). I took the
code from set_error_handler and that does not seem to work in this
instance - if I called the function with trigger_error then yes, it was
ok, but the memory fail still caused the crash.

Please note here, I dont really want to have to use eval - it is a null
function in this situation, it only seemed (from the manual) provide a
solution to my issue.

Removing the eval (replacing the entire loop with a simple while(true){
$str .= $str . "."; } ) which undoubtly would crash after ten or so
loops, does not throw my exception on the fatal error!

There are other possible solutions which we may end up implementing
which include a success monitor, ie each run enteres into a database a
"start" and a "end" and then at some other time, another script can
check for scripts that have started but not ended (ie crashed) and
provide analysis, alerts and fixes for.

> If you are using PHP 5, a try/catch block may also be useful to consider.

I am not (alas).

> I suspect that eval() DOES return false, once you get the error_reporting
> under control instead of relying on the rather crude default error
> handling.

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.

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.

James Taylor

[Back to original message]