ID: 9136
Updated by: yohgaki
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Closed
Bug Type: Feature/Change Request
Operating System: red hat 7.0
PHP Version: 4.0.4pl1
New Comment:
It's users responsibility to make sure script does not exeute forever.
Won't change.
If PHP segfaults with --enable-memory-limit, submit new bug report.
Previous Comments:
------------------------------------------------------------------------
[2001-02-06 18:17:07] [EMAIL PROTECTED]
I agree that recursion like this is not a good thing, it was an
accidental bug in a very complex PHP module we were writing. The
problem is that it's an incredibly difficult bug to find when PHP just
seg faults and you get a No Data error from Netscape. When you are
coding a very complex module as we were, the problem is not immediately
obvious as in this example.
I would expect buggy PHP code like this to give me a stack overflow
error report or execution time exceeded error or something. I just sat
there for about 5 minutes going WHAT!?!?! when I made a set of changes
and suddenly PHP started seg faulting all over the place.
I agree that an ini setting to check the stack level against a maximum
sounds like a good idea. I think it would be good to have on by
default (not just safe mode) given that many PHP developers are new
programmers who can easily make recursion mistakes (not to mention more
experienced php coders like me who still easily make recursion mistakes
;). Just set the value to something large enough to catch these
recursion bugs without effecting the running of most normal recursive
applications. True maniacs can turn it off by setting to -1 or
something. I prefer to be protected from myself until I'm ready to
grow out of the protection... <grin>
------------------------------------------------------------------------
[2001-02-06 17:41:12] [EMAIL PROTECTED]
maybe we should move this to feature request for safe mode?
it would be fine to give the server owner the possibility to
autokill scripts which would kill the server in a few
microseconds, shouldn't it be implementable without loosing
performance, check the level the stack is filled up against
a values in php.ini maybe...
------------------------------------------------------------------------
[2001-02-06 17:31:02] [EMAIL PROTECTED]
and guess this "bug" was present in any version before, what
do you expect to happen here? you will never leave these
function calls (as you know I guess), as far as your stack
is full it is full
remember php has to remember each and every function call it
did...
a()
b()
a()
b()
....
if you really need exactly this construct, I would suggest
you to use a static variable to count the total function
calls and find the critical values a specific system
segfaults (with your original code), then you stick a
for(;;) around it and implement a check (eg. in a()) against
the static variable to leave the recursion if a value with
enough distance to the critical value is reached, then you
should be able to begin the recursion again
any recursion can be displayed as a loop, do not use
recursion if you want to recurse infinitely
------------------------------------------------------------------------
[2001-02-06 17:22:36] [EMAIL PROTECTED]
PHP doesn't handle infinite recursion, and as earlier was discussed on
the php-dev list, it wont be implemented to guard for this, because of
the high performance impact.
------------------------------------------------------------------------
[2001-02-06 17:18:03] [EMAIL PROTECTED]
-------------------
<%
function a () {
b();
}
function b () {
a();
}
a();
%>
<h1>done</h1>
---------------------
The simple script above causes a seg fault. If you need more info on
configuration etc please mail me. We made this simple example from a
more compilcated instance. This bug was also present in 4.0.3pl1, we
upgraded to try and stop the seg fault...
thanks!
------------------------------------------------------------------------
Edit this bug report at http://bugs.php.net/?id=9136&edit=1
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
