Hello,
On 10/04/2004 11:53 AM, Olaf Van Der Spek wrote:
Why?
I think a large number of data handling functions would benefit from
such a function.
And it'd make PHP more robust.
Because it is an hack to work around the lack of support for detection
of corrupted data in zlib.
In the end you
David Bevan wrote:
On October 3, 2004 12:46, Olaf van der Spek wrote:
Manuel Lemos wrote:
Hello,
On 10/03/2004 12:27 PM, Olaf Van Der Spek wrote:
I think that making all failed memory allocations recoverable is not
viable because more PHP C code that makes memory allocations assumes
it only
Manuel Lemos wrote:
Hello,
On 10/03/2004 01:46 PM, Olaf Van Der Spek wrote:
Why?
I think a large number of data handling functions would benefit from
such a function.
And it'd make PHP more robust.
Because it is an hack to work around the lack of support for detection
of corrupted data in zlib.
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
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,
Hello,
On 10/03/2004 10:18 AM, Olaf Van Der Spek wrote:
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
Manuel Lemos wrote:
Hello,
I think that making all failed memory allocations recoverable is not
viable because more PHP C code that makes memory allocations assumes it
only returns if it succeeds. Trying to change that everywhere memory is
allocated is and monster job that I doubt that any PHP
Hello,
On 10/03/2004 12:27 PM, Olaf Van Der Spek wrote:
I think that making all failed memory allocations recoverable is not
viable because more PHP C code that makes memory allocations assumes
it only returns if it succeeds. Trying to change that everywhere
memory is allocated is and monster
Manuel Lemos wrote:
Hello,
On 10/03/2004 12:27 PM, Olaf Van Der Spek wrote:
I think that making all failed memory allocations recoverable is not
viable because more PHP C code that makes memory allocations assumes
it only returns if it succeeds. Trying to change that everywhere
memory is
Hello,
On 10/03/2004 01:46 PM, Olaf Van Der Spek wrote:
I think that making all failed memory allocations recoverable is not
viable because more PHP C code that makes memory allocations assumes
it only returns if it succeeds. Trying to change that everywhere
memory is allocated is and monster
On October 3, 2004 12:46, Olaf van der Spek wrote:
Manuel Lemos wrote:
Hello,
On 10/03/2004 12:27 PM, Olaf Van Der Spek wrote:
I think that making all failed memory allocations recoverable is not
viable because more PHP C code that makes memory allocations assumes
it only returns if
Manuel Lemos 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
Hello,
On 10/01/2004 08:54 AM, Olaf Van Der Spek wrote:
What is the PHP policy regaring crashes and fatal errors?
Are scripts allowed to cause a crash or fatal error of Apache/PHP itself?
A PHP served request can only crash if there is a bug that makes it crash.
Under Apache pre-fork model only
Manuel Lemos wrote:
Hello,
On 10/01/2004 08:54 AM, Olaf Van Der Spek wrote:
What is the PHP policy regaring crashes and fatal errors?
Are scripts allowed to cause a crash or fatal error of Apache/PHP itself?
A PHP served request can only crash if there is a bug that makes it crash.
Sure. But what
Hello,
On 10/01/2004 09:41 AM, Olaf Van Der Spek wrote:
What is the PHP policy regaring crashes and fatal errors?
Are scripts allowed to cause a crash or fatal error of Apache/PHP
itself?
A PHP served request can only crash if there is a bug that makes it
crash.
Sure. But what is the answer to
Manuel Lemos wrote:
Hello,
On 10/01/2004 09:41 AM, Olaf Van Der Spek wrote:
What is the PHP policy regaring crashes and fatal errors?
Are scripts allowed to cause a crash or fatal error of Apache/PHP
itself?
A PHP served request can only crash if there is a bug that makes it
crash.
Sure. But
Hello,
On 10/01/2004 10:00 AM, Olaf Van Der Spek wrote:
Is a (bug in a) script allowed to cause such a crash?
Not bugs in a script but rather in the PHP engine. In theory, the PHP
engine should never crash but there is no such thing as bug free
software.
So if I report a script that causes
Manuel Lemos wrote:
Hello,
On 10/01/2004 10:00 AM, Olaf Van Der Spek wrote:
Is a (bug in a) script allowed to cause such a crash?
Not bugs in a script but rather in the PHP engine. In theory, the PHP
engine should never crash but there is no such thing as bug free
software.
So if I report a
Hello,
On 10/01/2004 10:12 AM, Olaf Van Der Spek wrote:
Is a (bug in a) script allowed to cause such a crash?
Not bugs in a script but rather in the PHP engine. In theory, the
PHP engine should never crash but there is no such thing as bug free
software.
So if I report a script that causes
Manuel Lemos wrote:
Hello,
On 10/01/2004 10:12 AM, Olaf Van Der Spek wrote:
So what went wrong with this bug report?
http://bugs.php.net/bug.php?id=30153
It's marked as bogus, although it provides a script to reproduce the
crash.
That is not a crash. Your script making a PHP function request
Manuel Lemos wrote:
That is not a crash. Your script making a PHP function request 600MB of
memory. Since it exceeds the configured memory limit, there is no way to
recover from memory exhaustion and the script just exits cleanly. It
BTW, I don't agree. It's easily possible to recover from this
Hello,
On 10/01/2004 10:29 AM, Olaf Van Der Spek wrote:
So what went wrong with this bug report?
http://bugs.php.net/bug.php?id=30153
It's marked as bogus, although it provides a script to reproduce the
crash.
That is not a crash. Your script making a PHP function request 600MB
of memory. Since
Hello,
On 10/01/2004 10:32 AM, Olaf Van Der Spek wrote:
That is not a crash. Your script making a PHP function request 600MB
of memory. Since it exceeds the configured memory limit, there is no
way to recover from memory exhaustion and the script just exits
cleanly. It
BTW, I don't agree.
Manuel Lemos wrote:
On 10/01/2004 10:29 AM, Olaf Van Der Spek wrote:
So Apache restarts just because it thinks that's funny?
FATAL: erealloc(): Unable to allocate 603602944 bytes
[Sun Sep 19 16:11:16 2004] [notice] Parent: child process exited with
status 1 -- Restarting.
I was not aware that
Manuel Lemos wrote:
Hello,
On 10/01/2004 10:32 AM, Olaf Van Der Spek wrote:
That is not a crash. Your script making a PHP function request 600MB
of memory. Since it exceeds the configured memory limit, there is no
way to recover from memory exhaustion and the script just exits
cleanly. It
Manuel Lemos wrote:
I was not aware that memory allocation failures could make PHP to exit
its process but since it seems intentional there must be a reasoning
behind that for which I am not the person that should explain. Maybe the
reason has to due to the fact that when memory allocation
Hello,
On 10/01/2004 11:14 AM, Olaf Van Der Spek wrote:
So Apache restarts just because it thinks that's funny?
FATAL: erealloc(): Unable to allocate 603602944 bytes
[Sun Sep 19 16:11:16 2004] [notice] Parent: child process exited with
status 1 -- Restarting.
I was not aware that memory
Hello,
On 10/01/2004 11:15 AM, Olaf Van Der Spek wrote:
That is not a crash. Your script making a PHP function request 600MB
of memory. Since it exceeds the configured memory limit, there is no
way to recover from memory exhaustion and the script just exits
cleanly. It
BTW, I don't agree. It's
Manuel Lemos wrote:
If it is not normal, why don't you just evaluate the expected memory
size that is going to be allocated before calling the PHP function that
does it and handle the situation within your PHP code?
Because I've no idea how gzinflate decides how much memory to allocate.
--
PHP
Hello,
On 10/01/2004 11:20 AM, Olaf Van Der Spek wrote:
I was not aware that memory allocation failures could make PHP to exit
its process but since it seems intentional there must be a reasoning
behind that for which I am not the person that should explain. Maybe
the reason has to due to the
Hello,
On 10/01/2004 11:34 AM, Olaf Van Der Spek wrote:
If it is not normal, why don't you just evaluate the expected memory
size that is going to be allocated before calling the PHP function
that does it and handle the situation within your PHP code?
Because I've no idea how gzinflate decides
Manuel Lemos wrote:
Hello,
On 10/01/2004 11:34 AM, Olaf Van Der Spek wrote:
If it is not normal, why don't you just evaluate the expected memory
size that is going to be allocated before calling the PHP function
that does it and handle the situation within your PHP code?
Because I've no idea
Manuel Lemos wrote:
Hello,
On 10/01/2004 11:20 AM, Olaf Van Der Spek wrote:
I was not aware that memory allocation failures could make PHP to
exit its process but since it seems intentional there must be a
reasoning behind that for which I am not the person that should
explain. Maybe the reason
Manuel Lemos wrote:
If you do not think that discussing your alternative solution is worth
doing in php-dev, I do not think that keep discussing it php-general is
helping anybody.
I will post there.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit:
Hello,
On 10/01/2004 11:42 AM, Olaf Van Der Spek wrote:
If it is not normal, why don't you just evaluate the expected memory
size that is going to be allocated before calling the PHP function
that does it and handle the situation within your PHP code?
Because I've no idea how gzinflate decides
Hello,
On 10/01/2004 11:44 AM, Olaf Van Der Spek wrote:
But this does mean the policy does allow scripts to crash the
engine/server.
The way I see it, calling exit() is not a crash. If the code was
Indeed, I should've added or fatal error.
But from the script's point of view, it's the same as
Manuel Lemos wrote:
Hello,
On 10/01/2004 11:44 AM, Olaf Van Der Spek wrote:
But this does mean the policy does allow scripts to crash the
engine/server.
The way I see it, calling exit() is not a crash. If the code was
Indeed, I should've added or fatal error.
But from the script's point of
37 matches
Mail list logo
