ID: 26765
Comment by: jaanus at heeringson dot com
Reported By: alex_mailbox53 at yahoo dot com
Status: Critical
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2004-02-25
New Comment:
Hmm, I was totally wrong in my last posting. Of cause there are four
objects.
After updating my apache and php (from 20040307 to 20040309) the latest
test code works without causing segfaults now, even with print_r().
Anyway, since this bug is still making my life very miserabe, here
comes a new test case. This i a simplification of a object factory that
creates recursive trees.
<?php
class ObjFactory {
protected $child;
public function make($obj,$parent=null) {
$_temp=new $obj(array('factory'=>$this));
$this->child[$obj][]=$_temp;
if(is_object($parent)) {
$parent->mount($_temp);
}
Return $_temp;
}
}
class root {
protected $ref;
protected $chid;
protected $parent;
protected $test;
public function __construct($baseref) {
$this->ref=$baseref;
$this->ref['root']=$this;
print_r(array_keys($this->ref));
}
function mount($obj) {
$this->child[]=$obj;
$obj->setref($this->ref); //Both these lines individually
$obj->setParent($this); //cause the code to segfault
}
function setref($parentref) {
$this->ref=array_merge($parentref,$this->ref);
}
function setParent($parent) {
$this->parent=$parent;
}
}
class child extends root {
public function __construct($baseref) {
$this->ref=$baseref;
$this->ref['child']=$this;
print_r(array_keys($this->ref));
}
}
$factory=new ObjFactory();
$a=$factory->make('root');
$b=$factory->make('child',$a);
print_r($factory);
?>
Expected result:
----------------
Dump of the $factory object, with LOTS of cirular and recursive
relations
Actual result:
--------------
Segfault
gdb dump
--------------
Program received signal SIGSEGV, Segmentation fault.
zend_hash_destroy (ht=0x5a5a5a5a) at
/usr/src/lastphp/Zend/zend_hash.c:53
53 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 zend_hash_destroy (ht=0x5a5a5a5a) at
/usr/src/lastphp/Zend/zend_hash.c:53
#1 0x40b808de in zend_objects_free_object_storage (object=0x41646678)
at /usr/src/lastphp/Zend/zend_objects.c:88
#2 0x40b83145 in zend_objects_store_del_ref (zobject=0x1)
at /usr/src/lastphp/Zend/zend_objects_API.c:144
#3 0x40b6967d in _zval_dtor (zvalue=0x41646780,
__zend_filename=0x40d387e0
"/usr/src/lastphp/Zend/zend_execute_API.c",
__zend_lineno=1087946752) at
/usr/src/lastphp/Zend/zend_variables.c:61
#4 0x40b605b2 in _zval_ptr_dtor (zval_ptr=0x41652ac0,
__zend_filename=0x1 <Address 0x1 out of bounds>, __zend_lineno=1)
at /usr/src/lastphp/Zend/zend_execute_API.c:358
#5 0x40b69a71 in _zval_ptr_dtor_wrapper (zval_ptr=0x1)
at /usr/src/lastphp/Zend/zend_variables.c:196
#6 0x40b7307d in zend_hash_destroy (ht=0x41652840)
at /usr/src/lastphp/Zend/zend_hash.c:513
#7 0x40b696a9 in _zval_dtor (zvalue=0x416527c0,
__zend_filename=0x40d387e0
"/usr/src/lastphp/Zend/zend_execute_API.c",
__zend_lineno=1088082448) at
/usr/src/lastphp/Zend/zend_variables.c:52
#8 0x40b605b2 in _zval_ptr_dtor (zval_ptr=0x41651eb4,
__zend_filename=0x1 <Address 0x1 out of bounds>, __zend_lineno=1)
at /usr/src/lastphp/Zend/zend_execute_API.c:358
#9 0x40b69a71 in _zval_ptr_dtor_wrapper (zval_ptr=0x1)
at /usr/src/lastphp/Zend/zend_variables.c:196
---Type <return> to continue, or q <return> to quit---
#10 0x40b7307d in zend_hash_destroy (ht=0x416590e0)
at /usr/src/lastphp/Zend/zend_hash.c:513
#11 0x40b808de in zend_objects_free_object_storage (object=0x41659144)
at /usr/src/lastphp/Zend/zend_objects.c:88
#12 0x40b82f3f in zend_objects_store_free_object_storage
(objects=0x40dad400)
at /usr/src/lastphp/Zend/zend_objects_API.c:69
#13 0x40b60319 in shutdown_executor ()
at /usr/src/lastphp/Zend/zend_execute_API.c:272
#14 0x40b6ab56 in zend_deactivate () at
/usr/src/lastphp/Zend/zend.c:802
#15 0x40b29516 in php_request_shutdown (dummy=0x0)
at /usr/src/lastphp/main/main.c:1243
#16 0x40b9c47f in apache_php_module_main (r=0x865a050,
display_source_mode=0)
at /usr/src/lastphp/sapi/apache/sapi_apache.c:60
#17 0x40b9d2a8 in send_php (r=0x865a050, display_source_mode=0,
filename=0x0)
at /usr/src/lastphp/sapi/apache/mod_php5.c:621
#18 0x40b9c791 in send_parsed_php (r=0x1)
at /usr/src/lastphp/sapi/apache/mod_php5.c:636
#19 0x0805575b in ap_invoke_handler ()
#20 0x0806df68 in ap_update_mtime ()
#21 0x0806d324 in ap_process_request ()
#22 0x08066230 in suck_in_ap_validate_password ()
#23 0x08064c0d in suck_in_ap_validate_password ()
#24 0x08063c45 in suck_in_ap_validate_password ()
PS. I actually managed to get proper output from it ONCE, but I have
not been able to repeat the feat. Ill post an update if I succeed.
Previous Comments:
------------------------------------------------------------------------
[2004-03-07 17:46:52] jaanus at heeringson dot com
Actually, you only create 2 objects in the example above, the initial
foo and the bar from foo's constructor. The rest are only references.
I still get the "Segmentation fault (11)", and by debugging my own apps
i can only concurr that this is not solved. I also sometimes get some
kind of race-condition where the apache process heads up to 99.6%, but
this occurs rarely.
How come the "var_dump() to print_r()" matters? I get segfaults without
either (on the sample code). The segfaults only occur the second time
the code is run on the same process, not when initially loading the
page.
------------------------------------------------------------------------
[2004-02-29 16:46:44] awulf at ev1 dot net
-- quoting [EMAIL PROTECTED]
$t = &new foo();
$t->bar->add(new foo());
var_dump($t);
?>
This yields
object foo is being destroyed.
object bar is being destroyed.
object foo is being destroyed.
object bar is being destroyed.
-- end quote
this looks like it's doing the right thing to me. first you make a foo,
which in its constructor makes a bar. so you have 2 objects. then you
add another foo to the first foo's bar, which then creates another bar,
so you have 4 objects total. then they all get destroyed. looks good to
me, yeah?
------------------------------------------------------------------------
[2004-02-08 22:06:35] [EMAIL PROTECTED]
And several more notes follow.
- It seems circular references are now properly handled
with the new destructor code recently brought into the
engine by Zeev.
- As you know, in php5 objects are assigned to variables
by reference, so it'd be a fair comparison if the
script goes like this:
<?php
class foo {
var $bar = false;
var $parent = false;
function foo() {
$this->bar = &new bar($this);
}
function __destruct() {
echo "object ".__CLASS__." is being
destroyed.\n";
}
}
class bar {
var $foo = false;
var $items = array();
function bar(&$foo) {
$this->foo = &$foo;
}
function add(&$item) {
$this->items[] = &$item;
$item->parent = &$this->foo;
}
function __destruct() {
echo "object ".__CLASS__." is being
destroyed.\n";
}
}
$t = &new foo();
$t->bar->add(new foo());
var_dump($t);
?>
This yields
object foo is being destroyed.
object bar is being destroyed.
object foo is being destroyed.
object bar is being destroyed.
It looks like these objects have been destroyed twice...
- I wasn't able to reproduce the segfault even though I
changed var_dump() to print_r().
------------------------------------------------------------------------
[2004-02-08 21:43:31] [EMAIL PROTECTED]
The leaks are caused by circular references. So the only
remaining issue is the segfault bug.
Perhaps related to bug #25975
------------------------------------------------------------------------
[2004-02-08 11:51:51] [EMAIL PROTECTED]
Here is the backtrace when print_r() is used:
[Switching to Thread 16384 (LWP 27314)]
0x082cd5a8 in zend_std_compare_objects (o1=0x40e4306c, o2=0xbfffd580)
at /usr/src/web/php/php5/Zend/zend_object_handlers.c:843
843 if (zobj1->ce != zobj2->ce) {
(gdb) bt
#0 0x082cd5a8 in zend_std_compare_objects (o1=0x40e4306c,
o2=0xbfffd580)
at /usr/src/web/php/php5/Zend/zend_object_handlers.c:843
#1 0x082bba58 in zend_print_zval_r_ex (write_func=0x8285769
<php_body_write_wrapper>, expr=0x40e4306c, indent=0)
at /usr/src/web/php/php5/Zend/zend.c:366
#2 0x082bb99b in zend_print_zval_r (expr=0x40e4306c, indent=0) at
/usr/src/web/php/php5/Zend/zend.c:342
#3 0x0820b566 in zif_print_r (ht=1, return_value=0x40e439d4,
this_ptr=0x0, return_value_used=0)
at /usr/src/web/php/php5/ext/standard/basic_functions.c:2570
#4 0x082dd654 in zend_do_fcall_common_helper (execute_data=0xbfffd7c0,
opline=0x40e42f54, op_array=0x40e42674)
at /usr/src/web/php/php5/Zend/zend_execute.c:2558
#5 0x082ddc8a in zend_do_fcall_handler (execute_data=0xbfffd7c0,
opline=0x40e42f54, op_array=0x40e42674)
at /usr/src/web/php/php5/Zend/zend_execute.c:2700
#6 0x082da498 in execute (op_array=0x40e42674) at
/usr/src/web/php/php5/Zend/zend_execute.c:1272
#7 0x082bcad3 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/web/php/php5/Zend/zend.c:1051
#8 0x08285fd8 in php_execute_script (primary_file=0xbffffbc0) at
/usr/src/web/php/php5/main/main.c:1641
#9 0x080b776c in main (argc=2, argv=0xbffffc54) at
/usr/src/web/php/php5/sapi/cli/php_cli.c:941
------------------------------------------------------------------------
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/26765
--
Edit this bug report at http://bugs.php.net/?id=26765&edit=1
