php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #34617 zend_deactivate: objects_store used after zend_objects_store_destroy is called
Submitted: 2005-09-23 16:17 UTC Modified: 2005-09-27 20:11 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: guillaume dot outters at free dot fr Assigned: dmitry (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 5CVS, 6CVS (2005-09-23) OS: Mac OS X 10.4.2
Private report: No CVE-ID: None
 [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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-23 16:25 UTC] sniper@php.net
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:56 UTC] 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 20:06 UTC] sniper@php.net
Dmitry, this is not looking good. Can you check it out?

 [2005-09-24 15:11 UTC] tony2001@php.net
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-24 16:43 UTC] guillaume dot outters at free dot fr
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.
 [2005-09-27 20:11 UTC] dmitry@php.net
Fixed in CVS HEAD, PHP_5_1 and PHP_5_0.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 05:01:29 2024 UTC