#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