|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2005-09-23 16:17 UTC] 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 PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Tue Dec 03 17:01:29 2024 UTC |
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.