ID: 30153
Updated by: [EMAIL PROTECTED]
Reported By: OvdSpek at LIACS dot NL
-Status: Open
+Status: Bogus
Bug Type: Zlib Related
Operating System: *
PHP Version: 4CVS, 5CVS (20040929)
New Comment:
No, emalloc() and friends abort in case of a memory overflow, Checking
for the return value does not make any sense.
Previous Comments:
------------------------------------------------------------------------
[2004-10-01 11:17:11] OvdSpek at LIACS dot NL
> which results in graceful request termination.
Is a call to exit() graceful request termination?
In my opinion, that's just killing the entire process.
And in the case of a multi-threaded server, that's equivalent to
killing the entire server.
BTW, erealloc has an allow_failure parameter. How about passing true at
/php4/ext/zlib/zlib.c:628?
ZEND_API void *_erealloc(void *ptr, size_t size, int allow_failure
ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC)
------------------------------------------------------------------------
[2004-10-01 11:06:10] OvdSpek at LIACS dot NL
But /php4/ext/zlib/zlib.c is your code right? Not the code from the
zlib authors?
The bug isn't in zlib owned code, it's in php owned code, and that's
your code.
This code indeed expects to get NULL if erealloc fails.
Is there a flag for erealloc or function to use that doesn't 'cause an
exception' and instead just returns NULL?
s2 = (char *) erealloc(s1,length);
if(! s2) { if(s1) efree(s1); RETURN_FALSE; }
------------------------------------------------------------------------
[2004-10-01 09:45:13] [EMAIL PROTECTED]
Yes, you're the only one. Report to zlib authors if you don't like
Ilia's reply.
------------------------------------------------------------------------
[2004-09-30 23:54:48] OvdSpek at LIACS dot NL
Am I really the only one that does not find this an acceptable
solution?
The documentation states that this function will return an error and
that's what I expect. I do not expect my script to terminate.
> The function will return an error if the uncompressed data is more
than 32768 times the length of the compressed input data or more than
the optional parameter length.
------------------------------------------------------------------------
[2004-09-30 23:39:51] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Decompressing the specified file with non-php tools tells me that the
data is corrupt. As far as the error itself, according to the gzip
library return statuses the file's compression exceeds that of 1 to
32768 which is defined as upper limit. So this sort of behaviour is
expected. PHP cannot terminate nicely since the data size * 32768 still
tries to make PHP allocate too much memory, which results in graceful
request termination.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30153
--
Edit this bug report at http://bugs.php.net/?id=30153&edit=1
