I don't imagine how one really could calculate maximum depth without
solving the halting problem, so I must be missing something. I ask
somebody who knows what these patches are to send me a link - if there
were patches that do that automatically for any code I would very much
like to see them.
Adding the arbitrary - even configurable - limit doesn't seem to me the
correct solution, since it has high potential to break application code
Maybe I was a bit unspecific. If I recall correctly Nuno had some patch
(or was it someone else) that was keeping track of depth and maximum
stack size
and was deciding on the fly if another step deeper could crash. Of
course you need some sane detection.
For the record the patch I had is this:
http://mega.ist.utl.pt/~ncpl/zend_stack_protection.txt (it shouldn't apply
cleanly due to some changes in zend_try some time ago).
The approach of this patch is not to know in advance if there's still
available stack, but rather catch the SIGSEGV and bailout. I used this
approach in order to catch problems in external libraries, too. By that time
I was thinking in pcre, which was pretty easy to segfault with user-provided
data (now this is not the case because its internal recursion depth can be
limited - although with a PHP_INI_ALL config).
This approach is not very portable though, and by the time I was told that
probably it wouldn't play well with Apache signal handlers.
Knowing in advance if you can recurse or not doesn't sound much difficult in
theory.. You can get the limit (e.g. with getrlimit) then you can know how
much stack does a function call take, and then you can use a heuristic to
make the decision. This isn't 100% secure though (the limited depth approach
isn't too), but it's an option. I would love to ear how other VMs handle the
problem, like the JVM, anyone?
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
