php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #29599 domxml_error segfaults another apache module
Submitted: 2004-08-10 15:03 UTC Modified: 2004-08-13 14:21 UTC
From: thomas dot jarosch at intra2net dot com Assigned:
Status: Closed Package: DOM XML related
PHP Version: 4.3.8 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: thomas dot jarosch at intra2net dot com
New email:
PHP Version: OS:

 

 [2004-08-10 15:03 UTC] thomas dot jarosch at intra2net dot com
Description:
------------
Hi, 
 
we're running PHP 4.3.8 as apache module, Apache runs 
without threads. 
The domxml extension registers an libxml2 generic error 
handler during its initialization. 
We have another apache module, which makes use of libxml2, 
this one doesn't register an error handler. 
 
When then second apache module encounters an XML error, 
apache segfaults 
in the domxml_error function. Here's a backtrace of the 
problem: 
 
#0 ?0x404d3448 in php_apache_sapi_send_headers () 
from ./etc/httpd/modules/libphp4.so 
#1 ?0x4049c84e in sapi_send_headers () 
from ./etc/httpd/modules/libphp4.so 
#2 ?0x4045c456 in php_header () 
from ./etc/httpd/modules/libphp4.so 
#3 ?0x404a7518 in php_ub_body_write () 
from ./etc/httpd/modules/libphp4.so 
#4 ?0x404a63b3 in php_body_write () 
from ./etc/httpd/modules/libphp4.so 
#5 ?0x404952eb in php_printf () 
from ./etc/httpd/modules/libphp4.so 
#6 ?0x40495a4d in php_error_cb () 
from ./etc/httpd/modules/libphp4.so 
#7 ?0x404c165f in zend_error () 
from ./etc/httpd/modules/libphp4.so 
#8 ?0x40495698 in php_verror () 
from ./etc/httpd/modules/libphp4.so 
#9 ?0x4049576f in php_error_docref0 () 
from ./etc/httpd/modules/libphp4.so 
#10 0x403c6951 in domxml_error () 
from ./etc/httpd/modules/libphp4.so 
#11 0x4083cb86 in xmlReportError (err=0x81dc978, 
ctxt=0x81dc7f8, str=0x81e03b0 "Document is empty\n", 
channel=0x403c6910 <domxml_error>, data=0x0) 
? ? at error.c:283 
#12 0x4083ce9a in __xmlRaiseError (schannel=0, 
channel=0x4083d19c <xmlParserError__internal_alias>, 
data=0x81dc7f8, ctx=0x81dc7f8, nod=0x0, domain=1, 
? ? code=4, level=XML_ERR_FATAL, file=0x81df640 "", 
line=1, str1=0x0, str2=0x0, str3=0x0, int1=0, int2=0, 
msg=0x408d5111 "Document is empty\n") 
? ? at error.c:573 
#13 0x4083fef4 in xmlFatalErr (ctxt=0x81dc7f8, 
error=1080649792, info=0x51 <Address 0x51 out of bounds>) 
at parser.c:360 
#14 0x4084fa17 in xmlParseTryOrFinish (ctxt=0x81dc7f8, 
terminate=0) at parser.c:9098 
#15 0x40850358 in xmlParseChunk__internal_alias 
(ctxt=0x81dc7f8, chunk=0x81dc9e4 "????\003", size=228, 
terminate=0) at parser.c:9763 
#16 0x40cd108c in 
xmlpp::DomParser::parse_stream(std::istream&) 
(this=0xbfffeab0, in=@0xbfffecf0) at basic_string.h:781 
 
The problem is domxml's "global" error handler. Even if 
the second module would register an error handler, 
it would override PHP's error handler. IMHO the best 
approach would be to register the error handler 
only during operations calling libxml functions and 
deregister it afterwards. 
The performance overhead should be minimal and it's very 
clean. What do you think? 
 
Cheers, 
Thomas 
 

Actual result:
--------------
See backtrace in description 

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-08-10 16:15 UTC] chregu@php.net
The problem is fixed in PHP 5

Don't know, if "we" (meaning Rob) backport that to PHP 4...

Depends on how much work it is, I assume.
 [2004-08-11 10:28 UTC] thomas dot jarosch at intra2net dot com
Well, if it's not too much work, a backport would be nice. 
IMP v3 (webmail) doesn't support PHP5 yet, but I currently 
don't need domxml support and therefore disabled it. 
 
Thomas
 [2004-08-13 12:24 UTC] chregu@php.net
A fix is made, not committed yet.

If you have the possibility, could you check 
http://trash.chregu.tv/php_domxml.diff.txt

and see if it solves the problem?


 [2004-08-13 13:23 UTC] thomas dot jarosch at intra2net dot com
"Another job well done" :-) Works fine here! 
 
Though I'm curios where the 
xmlThrDefSetGenericErrorFunction is gone to. Won't this 
hurt threaded apaches or does the PHP_RINIT_FUNCTION take 
care of this?
 [2004-08-13 13:28 UTC] chregu@php.net
according to rob, it's not needed anymore (he did the patch anyway..)


 [2004-08-13 13:38 UTC] thomas dot jarosch at intra2net dot com
Ok. Thanks for the patch again! 
 
Thomas
 [2004-08-13 14:21 UTC] rrichards@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

xmlThrDefSetGenericErrorFunction no longer needed due to placement of the set error functions
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 14:01:29 2024 UTC