#24746 [NEW]: Fatal error: Nesting level too deep - recursive dependency?
From: tim at sparkart dot com
Operating system: Linux/FreeBSD
PHP version: 4.3.3RC1
PHP Bug Type: Reproducible crash
Bug description: Fatal error: Nesting level too deep - recursive dependency?
Description:
The code (attached) produces the following error: Fatal error: Nesting
level too deep - recursive dependency? in /home/tim/www/crash2.php on line
15
I started getting this bug with some code we are running and did some
google searches and found something on the php-dev list (where the sample
code is from) from 9/22/02:
http://www.geocrawler.com/archives/3/5/2002/9/50/9731982/
This happens on our Linux and FreeBSD boxes running PHP 4.3.2, 4.3.1, and
I just installed the latest CVS version (php4-STABLE-200307212330) and got
the same error. For the CVS version I configured using ./configure and
ran it through the command line on a Red Hat 8 box.
I saw other mentions of this error floating around but couldn't find
anything recent so sorry if this is a repeat.
Reproduce code:
---
?php
class A {
var $b;
function A() { $this-b = new B($this); }
}
class B {
var $a;
function B($a) { $this-a = $a; }
}
$one = new A;
$two = $one;
if ($one == $two) { // -- fatal error here
echo Same object\n;
} else {
echo not the same object\n;
}
?
Expected result:
Expected it to not give a fatal error.
--
Edit bug report at http://bugs.php.net/?id=24746edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24746r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24746r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24746r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24746r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24746r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24746r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24746r=support
Expected behavior: http://bugs.php.net/fix.php?id=24746r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24746r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24746r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24746r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24746r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24746r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24746r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24746r=gnused
#24746 [Bgs]: Fatal error: Nesting level too deep - recursive dependency?
ID: 24746
User updated by: tim at sparkart dot com
Reported By: tim at sparkart dot com
Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux/FreeBSD
PHP Version: 4.3.3RC1
New Comment:
Under Comparing objects in PHP 4
(http://www.php.net/manual/en/language.oop.object-comparison-php4.php)
it says:
In PHP 4, objects are compared in a very simple manner, namely: Two
object instances are equal if they have the same attributes and values,
and are instances of the same class.
So wouldn't the expected result of Same Object match this
description?
Previous Comments:
[2003-07-21 20:41:21] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Your object looks like this:
object(a)#1 (1) {
[b]=
object(b)#2 (1) {
[a]=
object(a)#1 (1) {
[b]=
object(b)#2 (1) {
[a]=
*RECURSION*
}
}
}
}
Which should explain the error message you are seeing.
[2003-07-21 19:56:57] tim at sparkart dot com
Description:
The code (attached) produces the following error: Fatal error: Nesting
level too deep - recursive dependency? in /home/tim/www/crash2.php on
line 15
I started getting this bug with some code we are running and did some
google searches and found something on the php-dev list (where the
sample code is from) from 9/22/02:
http://www.geocrawler.com/archives/3/5/2002/9/50/9731982/
This happens on our Linux and FreeBSD boxes running PHP 4.3.2, 4.3.1,
and I just installed the latest CVS version (php4-STABLE-200307212330)
and got the same error. For the CVS version I configured using
./configure and ran it through the command line on a Red Hat 8 box.
I saw other mentions of this error floating around but couldn't find
anything recent so sorry if this is a repeat.
Reproduce code:
---
?php
class A {
var $b;
function A() { $this-b = new B($this); }
}
class B {
var $a;
function B($a) { $this-a = $a; }
}
$one = new A;
$two = $one;
if ($one == $two) { // -- fatal error here
echo Same object\n;
} else {
echo not the same object\n;
}
?
Expected result:
Expected it to not give a fatal error.
--
Edit this bug report at http://bugs.php.net/?id=24746edit=1
#24174 [Com]: Seg. fault when calling imagecreatefromstring
ID: 24174
Comment by: tim at sparkart dot com
Reported By: legion at altlinux dot org
Status: Closed
Bug Type: GD related
Operating System: ALTLinux
PHP Version: 4.3.2
New Comment:
I ran into this same issue and went and spent some time debugging it.
Here is the backtrace:
#0 0x40359f9d in _int_free () from /lib/libc.so.6
#1 0x40358dda in free () from /lib/libc.so.6
#2 0x400c3e3f in gdFree (ptr=0x8224114) at gdhelpers.c:100
#3 0x400bae28 in gdFreeDynamicCtx (ctx=0x8224114) at gd_io_dp.c:154
#4 0x0806dcaa in _php_image_create_from_string (data=0x82105c4,
tn=0x81922e2 JPEG,
ioctx_func_p=0x806433c gdImageCreateFromJpegCtx) at
/usr/local/build/php-4.3.2/ext/gd/gd.c:1286
#5 0x0806de1f in zif_imagecreatefromstring (ht=1,
return_value=0x8215ed4, this_ptr=0x0, return_value_used=1)
at /usr/local/build/php-4.3.2/ext/gd/gd.c:1315
#6 0x08189f24 in execute (op_array=0x8216074) at
/usr/local/build/php-4.3.2/Zend/zend_execute.c:1606
#7 0x0817838c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/build/php-4.3.2/Zend/zend.c:869
#8 0x081442d3 in php_execute_script (primary_file=0xb830) at
/usr/local/build/php-4.3.2/main/main.c:1671
#9 0x081908dc in main (argc=2, argv=0xb8e4) at
/usr/local/build/php-4.3.2/sapi/cgi/cgi_main.c:1501
#10 0x402fadc4 in __libc_start_main () from /lib/libc.so.6
It looks like the cause of the seg fault is the GD library (I used
gd-2.0.15gif) trying to free some of the memory that php is using.
Specifically php's pointer to the image data.
So the work around was to null out the data pointer on php's side
before it made its call to GD to free up stuff it was using.
Details:
The call made from php that eventually causes the seg fault is in
ext/gd/gd.c around line 1284 in the _php_image_create_from_string
function:
io_ctx-gd_free(io_ctx);
This calls the gdFreeDynamicCtx function in gd_io_dp.c (line 141 in my
copy).
To null out the data pointer contained under the io_ctx variables to
prevent GD from trying to free the memory I added the following above
the gd_free call:
**((void***)(io_ctx+1)) = NULL;
Its kinda messy since we don't have access to any of the GD structs.
The equivalent code on the GD side of things, for example in the
gdFreeDynamicCtx function, would be something like:
((dynamicPtr*)((dpIOCtx*)ctx)-dp)-data = NULL;
Here is what the whole section of code in ext/gd/gd.c looks like (in my
copy):
...
if (!im) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Passed
data is not in '%s' format, tn);
return NULL;
}
// tp - 7/2/2003 - we don't want gd trying to free() our data
**((void***)(io_ctx+1)) = NULL;
#if HAVE_LIBGD204
io_ctx-gd_free(io_ctx);
#else
io_ctx-free(io_ctx);
#endif
...
PHP's built in Gd library doesn't try to free the PHP's data so this
work around shouldn't effect any of the built in stuff (assuming the
structs have the same layouts).
Previous Comments:
[2003-06-16 13:33:13] [EMAIL PROTECTED]
Not really, but what do you want us to do? We can't fix segfaults in
3rd-party libraries. Well, we can, we can fix them and redistribute
them, exactly like we are doing. So either use the 3rd-party stuff and
hope you get one which doesn't segfault or use the one we bundle that
we have tested and fixed.
[2003-06-16 13:25:43] legion at altlinux dot org
This is the official position of mantainers of this module ? You don't
support external GD library and use your own fork. Am i right ?
[2003-06-16 13:00:15] [EMAIL PROTECTED]
Then next bug is: i can't use function
imagegif() in your solution. Can i post it ?
No, this is not a bug. Even Boutell does not support gif export.
I strongly suggest you to use only the bundled GD (and thinking about
alternatives for the gif format), its quality and its integration to
php is really better.
pierre
[2003-06-16 12:40:21] legion at altlinux dot org
This is not the solution at all. Then next bug is: i can't use
function imagegif() in your solution. Can i post it ?
[2003-06-16 11:54:26] [EMAIL PROTECTED]
There is the solution then, use the bundled library (which has some
bugs fixed the external one hasn't)
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/24174
--
Edit this bug report at http://bugs.php.net/?id=24174edit=1
