Manuel Lemos wrote:
Hello,
On 10/02/2004 06:01 PM, Olaf Van Der Spek wrote:
AFAIK PHP runs safely in multi-threaded servers. What you can't expect is that PHP handles abnormal situations caused by flaws in the external libraries that PHP links with.
When I link with the same library in a C app, this 'abnormal situation' just results in a normal return from 'gzinflate' with an error value.
So why is it a flaw in code from zlib?
That is not the problem. The problem is that zlib does not seem to be able to detect and deal with corrupted streams. That leads to requesting absurd amounts of memory that the PHP memory allocator has no way to distinguish whether it is an intentional memory space request or something case by an abnormal situation.
It is not up to PHP memory allocator to guess what is going on. So it
It indeed isn't. However, it should be possible for the zlib code to say to the allocator: "Try to allocate this, if that fails, return an error to me instead of aborting the script".
handles like an normal memory allocation, gracefully exits like in any other operations that request space above the configured limits.
Gracefully, as in aborting/resetting the TCP/HTTP connection?
If zlib was ready to detect corruption it would never request an absurd amount of memory. I do not think it would be wise to change the PHP memory allocator behavior just to deal with zlib inability to detect corruption before asking for exceedingly large memory blocks.
I disagree, see above.
The flaw is in your code as nobody should be writing infinite recursion programs.
No, there is A flaw in my code. That doesn't mean it's THE flaw.
If you run a similar program in C it will crash exceeding the acceptable calling stack space. I don't know if you do that in PHP that could be avoided as I don't know if PHP can determine whether the stack space was exceeded.
Anyway, the only way to deal with this situation is to let the current
How can you claim that's the only way if you don't know whether it's avoidable by PHP?
process exit as there is no way to recover from this situation that is evidently a bug of the script, not of PHP.
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
