php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #28286 mod_php crash after xslt_process()
Submitted: 2004-05-05 16:45 UTC Modified: 2004-05-27 01:00 UTC
From: stuart dot herbert at boxuk dot com Assigned:
Status: No Feedback Package: DOM XML related
PHP Version: 4.3.6 OS: RHES 3.1
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: stuart dot herbert at boxuk dot com
New email:
PHP Version: OS:

 

 [2004-05-05 16:45 UTC] stuart dot herbert at boxuk dot com 
Description:
------------
PHP segfaults when shutting down.  This appears to be the same symptom as in bug #26384.  I've included a backtrace, and some dumps of what looked like the key structures.

Hope you can help,
Stu

Actual result:
--------------
#0  0xb70b47db in zend_hash_index_find (ht=0x40, h=0, pData=0x40)
    at /root/BoxUK3/build/php-4.3.6/Zend/zend_hash.c:960
#1  0xb6fac42a in node_wrapper_free (node=0x84c7458)
    at /root/BoxUK3/build/php-4.3.6/ext/domxml/php_domxml.c:651
#2  0xb6fac53c in node_list_wrapper_dtor (node=0x84c7458, destroyref=1)
    at /root/BoxUK3/build/php-4.3.6/ext/domxml/php_domxml.c:698
#3  0xb6fac4c2 in node_list_wrapper_dtor (node=0x84c7418, destroyref=1)
    at /root/BoxUK3/build/php-4.3.6/ext/domxml/php_domxml.c:682
#4  0xb6fac4c2 in node_list_wrapper_dtor (node=0x84c73d8, destroyref=1)
    at /root/BoxUK3/build/php-4.3.6/ext/domxml/php_domxml.c:682
#5  0xb6fac4c2 in node_list_wrapper_dtor (node=0x84b2778, destroyref=1)
    at /root/BoxUK3/build/php-4.3.6/ext/domxml/php_domxml.c:682
#6  0xb6fac4c2 in node_list_wrapper_dtor (node=0x84a68d8, destroyref=1)
    at /root/BoxUK3/build/php-4.3.6/ext/domxml/php_domxml.c:682
#7  0xb6f9eaa3 in php_free_xml_doc (rsrc=0x40)
    at /root/BoxUK3/build/php-4.3.6/ext/domxml/php_domxml.c:682
#8  0xb70b5242 in list_entry_destructor (ptr=0x850a7f4)
    at /root/BoxUK3/build/php-4.3.6/Zend/zend_list.c:177
#9  0xb70b3ce8 in zend_hash_apply_deleter (ht=0xb725cba0, p=0x8511b54)
    at /root/BoxUK3/build/php-4.3.6/Zend/zend_hash.c:608
#10 0xb70b3d8c in zend_hash_graceful_reverse_destroy (ht=0xb725cba0)
    at /root/BoxUK3/build/php-4.3.6/Zend/zend_hash.c:674
#11 0xb70b540f in zend_destroy_rsrc_list (ht=0x40)
    at /root/BoxUK3/build/php-4.3.6/Zend/zend_list.c:233
#12 0xb70a64c9 in shutdown_executor ()
    at /root/BoxUK3/build/php-4.3.6/Zend/zend_execute_API.c:213
#13 0xb70ae8f5 in zend_deactivate ()
    at /root/BoxUK3/build/php-4.3.6/Zend/zend.c:667
#14 0xb70822f8 in php_request_shutdown (dummy=0x0)
    at /root/BoxUK3/build/php-4.3.6/main/main.c:996
#15 0xb70c2590 in php_apache_request_dtor (r=0x8189040)
    at /root/BoxUK3/build/php-4.3.6/sapi/apache2handler/sapi_apache2.c:461
#16 0xb70c288b in php_handler (r=0x8189040)
    at /root/BoxUK3/build/php-4.3.6/sapi/apache2handler/sapi_apache2.c:577
#17 0x080686c5 in ap_run_handler (r=0x8189040) at config.c:195
#18 0x08068cdf in ap_invoke_handler (r=0x8189040) at config.c:401
#19 0x080654a6 in ap_process_request (r=0x8189040) at http_request.c:288
#20 0x08060a8c in ap_process_http_connection (c=0x8182fb8) at http_core.c:293
#21 0x080722b5 in ap_run_process_connection (c=0x8182fb8) at connection.c:85
#22 0x08066d11 in child_main (child_num_arg=64) at prefork.c:694
#23 0x08066e64 in make_child (s=0x0, slot=1) at prefork.c:788
#24 0x08066f86 in startup_children (number_to_start=4) at prefork.c:806
#25 0x080677ad in ap_mpm_run (_pconf=0x80a05d0, plog=0x80ca678, s=0x80a2370)
    at prefork.c:1022
#26 0x0806dc4f in main (argc=3, argv=0xbfffb594) at main.c:660

At stack frame #2, I did some printing of the xmlNodePtr node.  I don't know if this is useful or not.

(gdb) print *node->parent->parent
$8 = {_private = 0x864e288, type = XML_ELEMENT_NODE,
  name = 0x84c1250 "\030?d\bicontent", children = 0x84c7418,
  last = 0x864e290, parent = 0x84b2778, next = 0x0, prev = 0x84c11d8,
  doc = 0x850db48, ns = 0x0, content = 0x0, properties = 0x0, nsDef = 0x0,
  psvi = 0x0, line = 0, extra = 0}
(gdb) print *node->parent->parent->parent
$9 = {_private = 0x0, type = XML_ELEMENT_NODE, name = 0x84c1268 "Module",
  children = 0x84c11d8, last = 0x84c73d8, parent = 0x84a68d8,
  next = 0x84c12a8, prev = 0x84ab0b0, doc = 0x850db48, ns = 0x0,
  content = 0x0, properties = 0x84c1218, nsDef = 0x0, psvi = 0x0, line = 0,
  extra = 0}
(gdb) print *node->parent->parent->parent->parent
$10 = {_private = 0x0, type = XML_ELEMENT_NODE, name = 0x84a6918 "Modules",
  children = 0x84ac800, last = 0x84c12a8, parent = 0x850dc48, next = 0x0,
  prev = 0x84b32b8, doc = 0x850db48, ns = 0x0, content = 0x0,
  properties = 0x0, nsDef = 0x0, psvi = 0x0, line = 0, extra = 0}
(gdb) print *node->parent->parent->parent->parent->Parent
There is no member named Parent.
(gdb) print *node->parent->parent->parent->parent->parent
$11 = {_private = 0x0, type = XML_ELEMENT_NODE, name = 0x8304bc8 "XmlOutput",
  children = 0x81e69f8, last = 0x84a68d8, parent = 0x850db48, next = 0x0,
  prev = 0x0, doc = 0x850db48, ns = 0x0, content = 0x0, properties = 0x0,
  nsDef = 0x0, psvi = 0x0, line = 0, extra = 0}

And, from stack frame #1, here's a print of zval * wrapper:

(gdb) print *wrapper
$12 = {value = {lval = 800, dval = 1.3580773101702994e-312, str = {
      val = 0x320 <Address 0x320 out of bounds>, len = 64}, ht = 0x320,
    obj = {ce = 0x320, properties = 0x40}}, type = 112 'p',
  is_ref = 23 '\027', refcount = 2136}

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-05-07 14:47 UTC] rrichards@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.

Can you also include the libxml and libxslt versions you are using?
 [2004-05-15 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2004-05-17 10:10 UTC] stuart dot herbert at boxuk dot com 
Hiya,

Sorry - I've been unable to create a short script to reproduce this fault yet.  Our CMS is a large application which uses DOM extensively.  Trying to find 20 or so lines to re-create the problem is non-trivial.

Can you supply a debugging patch, which will help capture additional information?

libxml is 2.6.9, and libxslt is 1.1.6.

Best regards,
Stu
 [2004-05-17 13:36 UTC] rrichards@php.net 
What does your xslt_process call look like?
No easy way to debug this without a script, but can you try forcing a copy on the document (there's an additional parameter that can be passed to xslt_process to force a doc copy). Not sure what you have for parameters, but try something like:
xslt->process(doc, NULL, NULL, NULL, 1);

See if it still crashes doing that. If it still does and you dont have a reproducing script then you will have to sit down with gdb and try to find where the problem is coming from.
 [2004-05-17 15:00 UTC] stuart dot herbert at boxuk dot com 
Hiya,

Erm, I'm a bit confused.  xslt isn't an object in PHP 4 ;-)  It sounds like you're talking about the xslt functionality that's new in PHP 5 ;-)

Our xslt_process call looks like this:

$output = xslt_process($this->processor, 'arg:/_xml', 'arg:/xsl', NULL, $arguments);

There's no documented parameter to xslt_process() to force a copy.

If I'm going to 'poke about' with gdb, it'd help if you could point me in the right direction.  The core dump isn't very helpful - if I understand it correctly, it's just saying that the Zend engine is dying after executing the script because something messed up the internal linked lists.  Some sort of patch that will catch the list corruption much closer to where it occurs would really help ;-)

Best regards,
Stu
 [2004-05-17 15:20 UTC] rrichards@php.net 
The crash you get is from domxml, not xslt extension (sablotron), so assumed you were using the libxslt functions. This being the case, without a reproducing script, debugging domxml is extremely difficult as you need to figure out where the issue between the engine, domxml and libxml lies.
 [2004-05-17 15:20 UTC] rrichards@php.net 
The crash you get is from domxml, not xslt extension (sablotron), so assumed you were using the libxslt functions. This being the case, without a reproducing script, debugging domxml is extremely difficult as you need to figure out where the issue between the engine, domxml and libxml lies.
 [2004-05-17 15:34 UTC] stuart dot herbert at boxuk dot com 
I appreciate the need for the smaller reproducing script - but I don't have one yet for you.  I don't know if it will be possible either - Amaxus is a large product that uses XML throughout.

Something is corrupting that list.  A patch that adds code to validate the list, and that makes calls to the list validation function, would help us track down the source of that corruption.  Can you help?

Thanks,
Stu
 [2004-05-17 23:16 UTC] rrichards@php.net 
A reproducing script is necessary. Please dont bother asking about a debugging patch as there are too many factors to even attempt that.
 [2004-05-27 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 26 05:01:30 2024 UTC