ID:               34617
 User updated by:  guillaume dot outters at free dot fr
 Reported By:      guillaume dot outters at free dot fr
 Status:           Assigned
 Bug Type:         Scripting Engine problem
 Operating System: Mac OS X 10.4.2
 PHP Version:      5CVS, 6CVS (2005-09-23)
 Assigned To:      dmitry
 New Comment:

OK, here we go for a shorter crasher:

<?php
class Thing {}
function boom()
{
    $reader = xml_parser_create();
    xml_set_object($reader, new Thing());
    die("here");
    xml_parser_free($reader);
}
boom();
?>

Some comments on the environment:

- crashes with CLI (that could be useful to speed up testing  
and avoid crashing your company's internet web server)
- Doesn't crash with the default Tiger PHP (4.3.11)
- Doesn't crash with my modification (freing the store after 
resources). That said, it was a quick fix, and I don't know 
the Zend engine sufficently to ensure it is safe in other 
situations.

Some comments on the crasher:

- dying() after the xml_parser_free doesn't crash anymore 
(the parser has been manually freed, so that's the same as 
freing resources before the objects_store).
- the code must be in a function to crash.


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

[2005-09-24 15:11:49] [EMAIL PROTECTED]

Yet another chicken-and-egg problem with resources and objects.
xml_parser uses object for callbacks that is already destroyed at the
time when the resource is being destroyed.

2 guillaume dot outters at free dot fr:
Please try to make a reproduce case shorter than 1.7Mb. 

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

[2005-09-23 20:06:38] [EMAIL PROTECTED]

Dmitry, this is not looking good. Can you check it out?


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

[2005-09-23 16:56:08] guillaume dot outters at free dot fr

Same exact problem with 5.1.0RC2-dev (only line numbers in the 
backtrace differ).

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

[2005-09-23 16:25:35] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Please don't report issues unless you can reproduce the with PHP 5.1
snaps too. 

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

[2005-09-23 16:17:25] guillaume dot outters at free dot fr

Description:
------------
In zend_deactivate:
shutdown_executor()
[…]
zend_destroy_rsrc_list()

The first one calls zend_objects_store_destroy() and, in my 
case, the second one, through an xml_parser_dtor(), uses 
zend_objects_store_del_ref(). Inevitably, I got a crash.

It seems that the XML parser (a resource) has kept 
references to Zend objects, because of a malformed XML; I 
don't know if, according to the Zend engine policy, it 
should have released them all or if it reveals a bug in the 
engine itself. What I know for sure is that commenting the 
zend_objects_store_destroy in zend_execute_API, and adding 
it to zend_deactivate() just before zend_ini_deactivate(), 
solves my problem.

I use an Apache 2.1.7beta, but I don't think this has 
anything to do with it; my Mac is a PPC. The problem was 
revealed by an EXC_BAD_ACCESS, so I just put a breakpoint in 
free() and wait for it to be called with its first parameter 
looking like the beginning of the memory zone accessed at 
the crashing point.

Reproduce code:
---------------
Here is my crasher:
http://guillaume.outters.free.fr/boum.tar.bz2
(uncompress in an Apache-accessible directory, everything should be
here; call http://localhost/…/boum/album.php)

racine.xml is the bad XML file (line 12: a closing "aff" instead of a
"lieu" one).

Maybe a simple parser with just an XML file read would reproduce the
problem. I didn't try.

Expected result:
----------------
No crash!

Actual result:
--------------
#0  0x0238e078 in zend_objects_store_del_ref 
(zobject=0x16ae108) at /tmp/php-src/Zend/zend_objects_API.c:
148
#1  0x02350874 in _zval_dtor_func (zvalue=0x16ae108, 
__zend_filename=0x2430a30 "/tmp/php-src/Zend/
zend_variables.h", __zend_lineno=35) at /tmp/php-src/Zend/
zend_variables.c:62
#2  0x0233804c in _zval_dtor (zvalue=0x16ae108, 
__zend_filename=0x2460fd0 "/tmp/php-src/Zend/
zend_execute_API.c", __zend_lineno=396) at /tmp/php-src/
Zend/zend_variables.h:35
#3  0x02338454 in _zval_ptr_dtor (zval_ptr=0x16adbc0, 
__zend_filename=0x245ae2c "/tmp/php-src/ext/xml/xml.c", 
__zend_lineno=374) at /tmp/php-src/Zend/zend_execute_API.c:
396
#4  0x022c6030 in xml_parser_dtor (rsrc=0x16ae048) at /tmp/
php-src/ext/xml/xml.c:374
#5  0x02370a34 in list_entry_destructor (ptr=0x16ae048) at /
tmp/php-src/Zend/zend_list.c:184
#6  0x0236aff8 in zend_hash_apply_deleter (ht=0x251cf14, 
p=0x16adfe8) at /tmp/php-src/Zend/zend_hash.c:668
#7  0x0236b348 in zend_hash_graceful_reverse_destroy 
(ht=0x251cf14) at /tmp/php-src/Zend/zend_hash.c:734
#8  0x02370c9c in zend_destroy_rsrc_list (ht=0x251cf14) at /
tmp/php-src/Zend/zend_list.c:240
#9  0x02355b4c in zend_deactivate () at /tmp/php-src/Zend/
zend.c:1602


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


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

Reply via email to