#29599 [Opn]: domxml_error segfaults another apache module
ID: 29599 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com Status: Open Bug Type: DOM XML related Operating System: Linux PHP Version: 4.3.8 New Comment: Ok. Thanks for the patch again! Thomas Previous Comments: [2004-08-13 13:28:21] [EMAIL PROTECTED] according to rob, it's not needed anymore (he did the patch anyway..) [2004-08-13 13:23:57] 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 12:24:04] [EMAIL PROTECTED] 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-11 10:28:10] 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-10 16:15:50] [EMAIL PROTECTED] 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/29599 -- Edit this bug report at http://bugs.php.net/?id=29599&edit=1
#29599 [Opn]: domxml_error segfaults another apache module
ID: 29599 Updated by: [EMAIL PROTECTED] Reported By: thomas dot jarosch at intra2net dot com Status: Open Bug Type: DOM XML related Operating System: Linux PHP Version: 4.3.8 New Comment: according to rob, it's not needed anymore (he did the patch anyway..) Previous Comments: [2004-08-13 13:23:57] 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 12:24:04] [EMAIL PROTECTED] 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-11 10:28:10] 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-10 16:15:50] [EMAIL PROTECTED] 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-10 15:03:04] 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 , data=0x0) at error.c:283 #12 0x4083ce9a in __xmlRaiseError (schannel=0, channel=0x4083d19c , 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 ) 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, [EMAIL PROTECTED]) 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 -- Edit this bug report at http://bugs.php.net/?id=29599&edit=1
#29599 [Opn]: domxml_error segfaults another apache module
ID: 29599 User updated by: thomas dot jarosch at intra2net dot com Reported By: thomas dot jarosch at intra2net dot com Status: Open Bug Type: DOM XML related Operating System: Linux PHP Version: 4.3.8 New Comment: 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 Previous Comments: [2004-08-10 16:15:50] [EMAIL PROTECTED] 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-10 15:03:04] 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 , data=0x0) at error.c:283 #12 0x4083ce9a in __xmlRaiseError (schannel=0, channel=0x4083d19c , 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 ) 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, [EMAIL PROTECTED]) 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 -- Edit this bug report at http://bugs.php.net/?id=29599&edit=1
#29599 [Opn]: domxml_error segfaults another apache module
ID: 29599 Updated by: [EMAIL PROTECTED] Reported By: thomas dot jarosch at intra2net dot com Status: Open Bug Type: DOM XML related Operating System: Linux PHP Version: 4.3.8 New Comment: 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. Previous Comments: [2004-08-10 15:03:04] 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 , data=0x0) at error.c:283 #12 0x4083ce9a in __xmlRaiseError (schannel=0, channel=0x4083d19c , 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 ) 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, [EMAIL PROTECTED]) 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 -- Edit this bug report at http://bugs.php.net/?id=29599&edit=1
