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.

Closing,

Derick

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

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

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 

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

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

One report per bug please. There is already one about
this. (suspended)