ID:               24811
 Updated by:       [EMAIL PROTECTED]
 Reported By:      xris at siliconmechanics dot com
-Status:           Open
+Status:           Feedback
 Bug Type:         Reproducible crash
 Operating System: redhat 7.3, 8 and 9
 PHP Version:      Irrelevant
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

The version is never irrelevant in a crash bug..
And your assumption is wrong =)

With PHP5-cvs:
            [107874] => b Object
                (
                    [a] => a Object
 *RECURSION*
                )

        )

)
/opt/dev/php/php5/Zend/zend_hash.c(374) :  Freeing 0x45660F20 (35
bytes), script=24811.php
Last leak repeated 107874 times
/opt/dev/php/php5/Zend/zend_hash.c(233) :  Freeing 0x45660EC4 (37
bytes), script=24811.php
Last leak repeated 107875 times
/opt/dev/php/php5/Zend/zend_API.c(677) :  Freeing 0x45660E70 (32
bytes), script=24811.php
/opt/dev/php/php5/Zend/zend_hash.c(154) : Actual location (location was
relayed)
Last leak repeated 107875 times
/opt/dev/php/php5/Zend/zend_execute.c(3037) :  Freeing 0x45660E0C (44
bytes), script=24811.php
/opt/dev/php/php5/Zend/zend_API.c(676) : Actual location (location was
relayed)
Last leak repeated 107875 times
/opt/dev/php/php5/Zend/zend_objects.c(95) :  Freeing 0x45660DC8 (12
bytes), script=24811.php
Last leak repeated 107875 times
/opt/dev/php/php5/Zend/zend_execute.c(3036) :  Freeing 0x45660D84 (16
bytes), script=24811.php
Last leak repeated 107875 times
/opt/dev/php/php5/Zend/zend_hash.c(408) :  Freeing 0x42F5103C (524288
bytes), script=24811.php
/opt/dev/php/php5/Zend/zend_hash.c(154) : Actual location (location was
relayed)
/opt/dev/php/php5/Zend/zend_execute.c(793) :  Freeing 0x42D6F4B8 (44
bytes), script=24811.php
/opt/dev/php/php5/Zend/zend_variables.c(122) : Actual location
(location was relayed)
Last leak repeated 1 time


107K items in the array and it didn't die.

PHP4-cvs:
            [40000] => b Object
                (
                    [a] => a Object
                        (
                            [items] => Array
 *RECURSION*
                        )

                )

        )

)
/opt/dev/php/php4/Zend/zend_hash.c(406) :  Freeing 0x091CB92C (35
bytes), script=24811.php
Last leak repeated 40000 times
/opt/dev/php/php4/Zend/zend_hash.c(178) :  Freeing 0x091CB884 (32
bytes), script=24811.php
Last leak repeated 40001 times
/opt/dev/php/php4/Zend/zend_API.c(594) :  Freeing 0x091CB824 (44
bytes), script=24811.php
/opt/dev/php/php4/Zend/zend_API.c(582) : Actual location (location was
relayed)
Last leak repeated 40001 times
/opt/dev/php/php4/Zend/zend_execute.c(1975) :  Freeing 0x091CB7E4 (12
bytes), script=24811.php
Last leak repeated 40001 times
/opt/dev/php/php4/Zend/zend_hash.c(262) :  Freeing 0x091CB734 (37
bytes), script=24811.php
Last leak repeated 40001 times
/opt/dev/php/php4/Zend/zend_hash.c(440) :  Freeing 0x4032D02C (262144
bytes), script=24811.php
/opt/dev/php/php4/Zend/zend_execute.c(774) :  Freeing 0x081F13AC (44
bytes), script=24811.php
/opt/dev/php/php4/Zend/zend_variables.c(122) : Actual location
(location was relayed)
Last leak repeated 1 time

40k objects worked just fine, but somewhere around 50k it died.

But there is no crash here. Just a couple of memleaks.


Previous Comments:
------------------------------------------------------------------------

[2003-07-25 16:43:15] xris at siliconmechanics dot com

Description:
------------
Can't upgrade, production environment.  Happens on 4.2.2 and earlier,
and I'm forced to assume that it's still happening on more modern
versions. 

Ran into this problem with a much more complicated piece of code. 
Basically, I have an array nested in an object.  The array contains
other objects that then reference the parent object ala circular
linked-list.

The provided example uses print_r to create an overflow, though my
actual code the overflow happens elsewhere (I can't figure out where in
my code the overflow is being generated, since I never actually
traversed the list, as print_r does).  I know that it's the same
problem because both print_r and my code stabilize the instant I remove
the recursive entry from the second object (luckily for me, it wasn't
needed).

Reproduce code:
---------------
class a {
        var $items = array();
        function a() {
        }
}
class b {
        var $a;
        function b(&$a) {
                $this->a = &$a;
        }
}
$a = new a();
$a->items[] = new b($a);
$a->items[] = new b($a);
$a->items[] = new b($a); # this much is ok
$a->items[] = new b($a); # the proverbial straw
print_r($a);

Expected result:
----------------
get a printout from print_r where all recursive entries are marked:

a Object
(
    [items] => Array
        (
            [0] => b Object
                (#
                    [a] => *RECURSION*
                )

            [1] => b Object
                (
                    [a] => *RECURSION*
                )
         )
)


Actual result:
--------------
With fewer items, the recursion is not properly detected, leading to an
overflow as more items are added.

With too many items in the array, nothing.  php dies, or something like
that.  IE produces a "page not found" error, and gecko just redisplays
whatever page was previously loaded, with no error returned (I expected
a "document contains no data" error, but never got it).




------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=24811&edit=1

Reply via email to