Re: Trapping "memory exhausted" error

From: Date: Tue, 17 Apr 2007 08:16:06 +0000
Subject: Re: Trapping "memory exhausted" error
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-28876@lists.php.net to get a copy of this message
On 4/16/07, Stanislav Malyshev <stas@zend.com> wrote:
- in addition to a memory_limit configuration directive, there could be a "memory_limit_grace" configuration directive. This gets stored in the struct _zend_mm_heap, along with the limit. That could be a problem because it's very hard to know exact memory requirements for PHP code for most people not intimately knowing the engine internals, and also recovering from failed allocation usually is not simple since management structures could be in half-done state. So writing useful handler for such an error would be rather hard to do. Having said that, what exactly would you plan to do in this error handler?
In my current situation, bail out, but gracefully -- perhaps just send a 302 to an error page and exit; maybe instead throw away the output buffer and then directly output some friendly error text. The idea would be not to recover from the failure and proceed with a separate script execution path that requires a lot less memory, but to have things fail more gracefully than just splatting a Fatal Error. So being able to calculate with great accuracy the memory requirements of particular bits of PHP code shouldn't be a prerequisite to making this sort of thing useful. That said, given the history of just about every other feature in PHP, it wouldn't be surprising for people to attempt to use this feature to do all sorts of crazy things after the soft memory limit has been reached, and in that case they'd want to be able to calculate the appropriate size of their grace period, but if they're going to go to such contortions, then that's what they're stuck with. David Richard Lynch <ceo@l-i-e.com> wrote:
You might also come at it from the other direction and detect/notify at some number smaller than the current hard limit, configurable in php.ini... This might play better with anything relying on the current behaviour
This is interesting and might actually take care of a lot of cases. I don't know enough about the existing memory manager to know if it would handle the case where a single new allocation would blow through both the (lower) soft limit and the hard limit at the same time. David

« previous php.internals (#28876) next »