Bug #13587 Updated: Recurence makes crash
| From: | sniper@php.net | Date: | Sun, 07 Oct 2001 20:25:24 +0000 |
| Subject: | Bug #13587 Updated: Recurence makes crash | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-67500@lists.php.net to get a copy of this message | ||
ID: 13587
Updated by: sniper
Reported By: kelcon@ceti.pl
Old Status: Open
Status: Bogus
Bug Type: Reproducible crash
Operating System: Win98
PHP Version: 4.0.6
New Comment:
One report per bug please. There is already one about
this. (suspended)
Previous Comments:
------------------------------------------------------------------------
[2001-10-07 16:05:17] jeroen@php.net
Derick wrote:
> Indeed, if we can make PHP not to crash, we'll certainly do so. But in this case it is NOT
> possible as I explained before.
You wrote before:
> There is no clean way to catch this. PHP does not support infinite recursion, as no language
> does.
> The performance hit is too big if this kind of checking was build in, and even then it's
> not very easy to do in a smart way.
That's a reason why PHP cannot check for this at compile time. But PHP can of course check at
runtime wether there are allocation problems. A "Error: out of memory " would be
apropriate, or a stack error. (don't know where exactly the segfault is being caused by, by
the hashtable allocation attempt, or because that hash table allocation gets a pointer to a location
outside the execution stack or something alike, in either case, a error would be appropriate and
possible, very likely without noticable performance hit)
--Jeroen
------------------------------------------------------------------------
[2001-10-07 15:51:43] derick@php.net
Indeed, if we can make PHP not to crash, we'll certainly do so. But in this case it is NOT
possible as I explained before.
I'm suspending this until there is a clever way to do it.
Derick
------------------------------------------------------------------------
[2001-10-07 15:48:02] jeroen@php.net
Backtrace:
#0 0x40176626 in sbrk () from /lib/libc.so.6
#1 0x4011d21e in __default_morecore () from /lib/libc.so.6
#2 0x4011a743 in malloc () from /lib/libc.so.6
#3 0x4011a134 in malloc () from /lib/libc.so.6
#4 0x080d512c in _emalloc (size=32) at zend_alloc.c:165
#5 0x080d5297 in _ecalloc (nmemb=8, size=4) at zend_alloc.c:257
#6 0x080e4c6b in zend_hash_init (ht=0x8541fbc, nSize=0, pHashFunction=0,
pDestructor=0x80da7fc <_zval_ptr_dtor>, persistent=0) at zend_hash.c:176
#7 0x080fd65a in execute (op_array=0x81792e4) at ./zend_execute.c:1616
#8 0x080fd71a in execute (op_array=0x81792e4) at ./zend_execute.c:1638
#9 0x080fd71a in execute (op_array=0x81792e4) at ./zend_execute.c:1638
<snip>
#24951 0x080fd71a in execute (op_array=0x81792e4) at ./zend_execute.c:1638
#24952 0x080fd71a in execute (op_array=0x81792e4) at ./zend_execute.c:1638
#24953 0x080fd71a in execute (op_array=0x8173034) at ./zend_execute.c:1638
#24954 0x080e204a in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at zend.c:814
#24955 0x0805fd16 in php_execute_script (primary_file=0xbffffb58)
at main.c:1310
#24956 0x0805de7c in main (argc=2, argv=0xbffffbd4) at cgi_main.c:737
#24957 0x400c56ef in __libc_start_main () from /lib/libc.so.6
Catching failure to do a
------------------------------------------------------------------------
[2001-10-07 15:28:43] jeroen@php.net
PHP shouldn't crash on this, rather a stack overflow error should be emitted. There's no
single circumstance that PHP may crash.
Of course it's impossible to check program logic at compile time, but a runtime error is
appropriate in this case.
Derick: Some languages DO support 'infinite' recursion (of course not in this way), they
use a technique called lazy evaluation.
Reproduced with latest CVS
------------------------------------------------------------------------
[2001-10-07 14:44:26] mfischer@php.net
What do you expect from an infinite recursion? You can't expect the parser knowing what you are
doing. What if you implement n! this way? How should the parser know it?
Btw, even perl segfaults on such things ;)
No bug -> bogusified.
- Markus
------------------------------------------------------------------------
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/?id=13587
Edit this bug report at http://bugs.php.net/?id=13587&edit=1