Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse

2004-04-23 Thread Andi Gutmans 
At 02:23 PM 4/22/2004 -0400, Rob Richards wrote:
From: Sterling Hughes

> I think you are off base in removing them.  We need them to hook into
> PHP's error handling system.  I think setting/resetting in RINIT
> instead of MINIT is a good place to start and see if that fixes the
> problem.   I personally could care less about the threaded case (i hope
> PHP stops using this TSRM stuff and just recommends FastCGI), although
> someone here who cares more may have opinions about that. I guess we
> could add an #ifdef TSRM to the system, and not set the generic error
> handler - if someone cares enough about the threaddites.
Sterling,

You're actually correct, go figure ;). I was backwards in the thread calls
for libxml. Putting into RINIT/SHUTDOWN works correctly for both the treaded
and non threaded systems (the current placement is what would cause problems
for threaded servers).
Andi, is it okay to commit this change right now?
Yes, please do.

Thanks,

Andi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse

2004-04-22 Thread Rob Richards 
From: Sterling Hughes

> I think you are off base in removing them.  We need them to hook into
> PHP's error handling system.  I think setting/resetting in RINIT
> instead of MINIT is a good place to start and see if that fixes the
> problem.   I personally could care less about the threaded case (i hope
> PHP stops using this TSRM stuff and just recommends FastCGI), although
> someone here who cares more may have opinions about that. I guess we
> could add an #ifdef TSRM to the system, and not set the generic error
> handler - if someone cares enough about the threaddites.

Sterling,

You're actually correct, go figure ;). I was backwards in the thread calls
for libxml. Putting into RINIT/SHUTDOWN works correctly for both the treaded
and non threaded systems (the current placement is what would cause problems
for threaded servers).

Andi, is it okay to commit this change right now?

Rob

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse

2004-04-22 Thread Sterling Hughes 
On Apr 22, 2004, at 5:09 AM, Rob Richards wrote:

From: Sterling Hughes


Err, read back in the message.  Specifically about "should reset the
generic error handler."  If it doesn't reset it, that's a separate
issue.  It has *nothing* todo with the mysql issue (which was symbol
conflicts due to two libraries being compiled into the same server).  
A
process can not execute two code paths at the same time, therefore you
cannot have such corruption in a prefork model.
Sterling, I also thought this might be in issue when I brought it up 
many
moons ago as I have no idea of the isolation in apache.
I just ran a debug session using apache 2.0.45 prefork under linux. 
MINIT is
only called on server startup and MSHUTDOWN is only called on server
shutdown. Since the error handling is set/unset in this spots, it gets
changed to our internal handling when apache first starts up and isn't 
reset
between requests. Only when apache shuts down is it reset.

Now either the apache 2 sapi is wrong in this regard or the error 
handling
really needs to be re-worked.

Here are a couple options I can think of:

Putting it in the RINIT/RSHUTDOWN should fix it (cant say about 
threaded
servers and threaded libxml as there was an issue with the per thread 
error
handing in libxml up to at least 2.5.11 - threaded libxml builds needed
xmlThrDefSetGenericErrorFunc to be set in the main thread which would 
have
to happen in MINIT (or the error handling needs to be set on every
request) - had only played around with this on windows though so not 
sure if
it affects non threaded web servers as well), not sure if this is ideal
since it would need to be run on every request wether using libxml or 
not.

Right, this wouldn't fix the threaded case.


If libxml error messages are only needed during loading of xml and 
possibly
some other spots where we have a context (such as SAX and possibly
validating, etc.. - havent looked at that), the custom error functions 
can
be attached directly to the context. Origionally I moved those custom 
error
functions to the libxml extension (as they used to only be used in dom 
in th
is manner) so that this could be the case, but ended up with just 
setting
the global error handler instead. For all other errors when dealing 
with
operations on the tree, would have to deal with errors through the
extensions alone.

My suggestion is to pull the 2 calls to xmlSetGenericErrorFunc from 
libxml.c
right now so that is resolved prior to RC2 going out the door (if 
possible).
Then just have to decide wether this should be worked on and 
implemented
prior to the 5.0 release or put on the list for 5.1.

Feel free to tell me if I am way off base here as I really have no 
idea of
the interaction between modules in apache :)

I think you are off base in removing them.  We need them to hook into 
PHP's error handling system.  I think setting/resetting in RINIT 
instead of MINIT is a good place to start and see if that fixes the 
problem.   I personally could care less about the threaded case (i hope 
PHP stops using this TSRM stuff and just recommends FastCGI), although 
someone here who cares more may have opinions about that. I guess we 
could add an #ifdef TSRM to the system, and not set the generic error 
handler - if someone cares enough about the threaddites.

-Sterling

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse

2004-04-22 Thread Rob Richards 
From: Sterling Hughes


> Err, read back in the message.  Specifically about "should reset the
> generic error handler."  If it doesn't reset it, that's a separate
> issue.  It has *nothing* todo with the mysql issue (which was symbol
> conflicts due to two libraries being compiled into the same server).  A
> process can not execute two code paths at the same time, therefore you
> cannot have such corruption in a prefork model.

Sterling, I also thought this might be in issue when I brought it up many
moons ago as I have no idea of the isolation in apache.
I just ran a debug session using apache 2.0.45 prefork under linux. MINIT is
only called on server startup and MSHUTDOWN is only called on server
shutdown. Since the error handling is set/unset in this spots, it gets
changed to our internal handling when apache first starts up and isn't reset
between requests. Only when apache shuts down is it reset.

Now either the apache 2 sapi is wrong in this regard or the error handling
really needs to be re-worked.

Here are a couple options I can think of:

Putting it in the RINIT/RSHUTDOWN should fix it (cant say about threaded
servers and threaded libxml as there was an issue with the per thread error
handing in libxml up to at least 2.5.11 - threaded libxml builds needed
xmlThrDefSetGenericErrorFunc to be set in the main thread which would have
to happen in MINIT (or the error handling needs to be set on every
request) - had only played around with this on windows though so not sure if
it affects non threaded web servers as well), not sure if this is ideal
since it would need to be run on every request wether using libxml or not.

If libxml error messages are only needed during loading of xml and possibly
some other spots where we have a context (such as SAX and possibly
validating, etc.. - havent looked at that), the custom error functions can
be attached directly to the context. Origionally I moved those custom error
functions to the libxml extension (as they used to only be used in dom in th
is manner) so that this could be the case, but ended up with just setting
the global error handler instead. For all other errors when dealing with
operations on the tree, would have to deal with errors through the
extensions alone.

My suggestion is to pull the 2 calls to xmlSetGenericErrorFunc from libxml.c
right now so that is resolved prior to RC2 going out the door (if possible).
Then just have to decide wether this should be worked on and implemented
prior to the 5.0 release or put on the list for 5.1.

Feel free to tell me if I am way off base here as I really have no idea of
the interaction between modules in apache :)

Rob

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse

2004-04-21 Thread Paul Querna 
On Wed, 2004-04-21 at 23:06, Sterling Hughes wrote:
> Err, read back in the message.  Specifically about "should reset the 
> generic error handler."  If it doesn't reset it, that's a separate 
> issue. 

see the attached patch.

it fixes this problem for my test case. Does not completely shutdown the
xmlParser between requests, but just fixes the error handling stuff.

-Paul Querna
Index: ext/libxml/libxml.c
===
RCS file: /repository/php-src/ext/libxml/libxml.c,v
retrieving revision 1.16
diff -u -r1.16 libxml.c
--- ext/libxml/libxml.c	1 Mar 2004 12:09:22 -	1.16
+++ ext/libxml/libxml.c	22 Apr 2004 05:29:57 -
@@ -400,9 +400,6 @@
 			php_libxml_streams_IO_write, 
 			php_libxml_streams_IO_close);
 
-		/* report errors via handler rather than stderr */
-		xmlSetGenericErrorFunc(NULL, php_libxml_error_handler);
-
 		zend_hash_init(&php_libxml_exports, 0, NULL, NULL, 1);
 
 		_php_libxml_initialized = 1;
@@ -411,8 +408,6 @@
 
 PHP_LIBXML_API void php_libxml_shutdown() {
 	if (_php_libxml_initialized) {
-		/* reset libxml generic error handling */
-		xmlSetGenericErrorFunc(NULL, NULL);
 		xmlCleanupParser();
 		zend_hash_destroy(&php_libxml_exports);
 		_php_libxml_initialized = 0;
@@ -436,7 +431,10 @@
 
 PHP_RINIT_FUNCTION(libxml)
 {
-return SUCCESS;
+	/* report errors via handler rather than stderr */
+	xmlSetGenericErrorFunc(NULL, php_libxml_error_handler);
+
+	return SUCCESS;
 }
 
 
@@ -450,6 +448,8 @@
 
 PHP_RSHUTDOWN_FUNCTION(libxml)
 {
+	/* reset libxml generic error handling */
+	xmlSetGenericErrorFunc(NULL, NULL);
 	smart_str_free(&LIBXML(error_buffer));
 	return SUCCESS;
 }



signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse

2004-04-21 Thread Sterling Hughes 
On Apr 21, 2004, at 6:16 PM, Paul Querna wrote:

On Wed, 2004-04-21 at 18:50, Sterling Hughes wrote:
Its actually quite different than that problem.  This is a problem for
people who use threads.
I am afraid that you are completely wrong.

httpd -V:
Server version: Apache/2.1.0-dev
Server built:   Feb 15 2004 14:26:54
Server's Module Magic Number: 20030821:3
Architecture:   32-bit
Server MPM: Prefork
  threaded: no
forked: yes (variable process count)
Server compiled with
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses disabled)
 -D APR_USE_FLOCK_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/home/httpd/local"
 -D SUEXEC_BIN="/home/httpd/local/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"
Yes. That is correct, I am using the PREFORK MPM, which is not
multi-threaded.  If I was using the worker MPM, i wouldn't even bother
submitting this because I know the PHP-Devs do not care about thread
safety.
and here is an example backtrace of this happening:

#0  php_apache_sapi_send_headers (sapi_headers=0x2857ce98)
at
/usr/home/httpd/src/php-src/sapi/apache2handler/sapi_apache2.c:140
#1  0x28472714 in sapi_send_headers () at
/usr/home/httpd/src/php-src/main/SAPI.c:747
#2  0x284230de in php_header () at
/usr/home/httpd/src/php-src/ext/standard/head.c:60
#3  0x28478f50 in php_ub_body_write (
str=0x8143154 "\nWarning:  I/O warning : failed to 
load
external entity \"docbooka/xsl/html/docbook.xsl\" in Unknown on
line 0\n", str_length=142) at
/usr/home/httpd/src/php-src/main/output.c:704
#4  0x28477fa9 in php_body_write (
str=0x8143154 "\nWarning:  I/O warning : failed to 
load
external entity \"docbooka/xsl/html/docbook.xsl\" in Unknown on
line 0\n", str_length=142) at
/usr/home/httpd/src/php-src/main/output.c:119
#5  0x2846b6e2 in php_printf (format=0x28502600 "%s\n%s:
%s in %s on line %d\n%s")
at /usr/home/httpd/src/php-src/main/main.c:400
#6  0x2846c05e in php_error_cb (type=2, error_filename=0x284fba9c
"Unknown", error_lineno=0, format=0x2850223d "%s",
args=0xbfbfe604 "ô0\024\b\n") at
/usr/home/httpd/src/php-src/main/main.c:736
#7  0x2849f356 in zend_error (type=2, format=0x2850223d "%s") at
/usr/home/httpd/src/php-src/Zend/zend.c:930
#8  0x2835fec4 in php_libxml_internal_error_handler (error_type=0,
ctx=0x0, msg=0x0, ap=0xbfbfe654 "")
at /usr/home/httpd/src/php-src/ext/libxml/libxml.c:351
#9  0x2835ffb0 in php_libxml_error_handler (ctx=0x0, msg=0x287339fb
"%s")
at /usr/home/httpd/src/php-src/ext/libxml/libxml.c:377
#10 0x286a48ab in xmlReportError (err=0x826b580, ctxt=0x826b400,
str=0x8269300 "failed to load external entity
\"docbooka/xsl/html/docbook.xsl\"\n",
channel=0x2835ff98 , data=0x0) at
error.c:381
#11 0x286a4d4b in __xmlRaiseError (schannel=0, channel=0x286a4f3e
, data=0x826b400, ctx=0x826b400, nod=0x0,
domain=8, code=1549, level=XML_ERR_WARNING, file=0x0, line=0,
str1=0x8249a20 "docbooka/xsl/html/docbook.xsl", str2=0x0,
str3=0x0, int1=0, int2=0, msg=0x28724b40 "failed to load external
entity \"%s\"\n") at error.c:573
#12 0x286c2b88 in __xmlLoaderErr (ctx=0x2857ce40, msg=0x28724b40 
"failed
to load external entity \"%s\"\n",
filename=0x8249a20 "docbooka/xsl/html/docbook.xsl") at xmlIO.c:426
#13 0x286a69f2 in xmlNewInputFromFile (ctxt=0x826b400,
filename=0x8249a20 "docbooka/xsl/html/docbook.xsl")
at parserInternals.c:1465
#14 0x286c4eed in xmlDefaultExternalEntityLoader (URL=0x82499e0
"docbooka/xsl/html/docbook.xsl", ID=0x0, ctxt=0x826b400)
at xmlIO.c:3176
#15 0x286c4f91 in xmlLoadExternalEntity (URL=0x8249a20
"docbooka/xsl/html/docbook.xsl", ID=0x0, ctxt=0x826b400)
at xmlIO.c:3233
#16 0x286b6f60 in xmlCreateURLParserCtxt (filename=0x826d300
"docbooka/xsl/html/docbook.xsl", options=16398) at parser.c:11039
#17 0x286b7dfe in xmlReadFile (filename=0x826d300
"docbooka/xsl/html/docbook.xsl", encoding=0x0, options=136754176)
at parser.c:12093
#18 0x2899ac0e in xsltParseStylesheetFile (filename=0x826d300
"docbooka/xsl/html/docbook.xsl") at xslt.c:2129
#19 0x2899b110 in xsltLoadStylesheetPI (doc=0x824ca00) at xslt.c:2357
#20 0x28a043ad in transform_run (f=0x8257f60, doc=0x826d300) at
mod_transform.c:182
#21 0x28a044d2 in transform_filter (f=0x8257f60, bb=0x825a120) at
mod_transform.c:249
#22 0x0806d8db in ap_pass_brigade (next=0x2857ce40, bb=0x2857ce40) at
util_filter.c:511
#23 0x0807412b in default_handler (r=0x8256050) at core.c:3513
#24 0x080630be in ap_run_handler (r=0x8256050) at config.c:151
#25 0x08063582 in ap_invoke_handler (r=0x8256050) at config.c:358
#26 0x08060a03 in ap_process_request (r=0x8256050) at 
http_request.c:246
#27 0x0805c639 in ap_process_http_connection (c=0x8250128) at
http_core.c:253
#28 0

Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse

2004-04-21 Thread Paul Querna 
On Wed, 2004-04-21 at 18:50, Sterling Hughes wrote:
> Its actually quite different than that problem.  This is a problem for 
> people who use threads. 

I am afraid that you are completely wrong.

httpd -V:
Server version: Apache/2.1.0-dev
Server built:   Feb 15 2004 14:26:54
Server's Module Magic Number: 20030821:3
Architecture:   32-bit
Server MPM: Prefork
  threaded: no
forked: yes (variable process count)
Server compiled with
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses disabled)
 -D APR_USE_FLOCK_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/home/httpd/local"
 -D SUEXEC_BIN="/home/httpd/local/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

Yes. That is correct, I am using the PREFORK MPM, which is not
multi-threaded.  If I was using the worker MPM, i wouldn't even bother
submitting this because I know the PHP-Devs do not care about thread
safety.

and here is an example backtrace of this happening:

#0  php_apache_sapi_send_headers (sapi_headers=0x2857ce98)
at
/usr/home/httpd/src/php-src/sapi/apache2handler/sapi_apache2.c:140
#1  0x28472714 in sapi_send_headers () at
/usr/home/httpd/src/php-src/main/SAPI.c:747
#2  0x284230de in php_header () at
/usr/home/httpd/src/php-src/ext/standard/head.c:60
#3  0x28478f50 in php_ub_body_write (
str=0x8143154 "\nWarning:  I/O warning : failed to load
external entity \"docbooka/xsl/html/docbook.xsl\" in Unknown on
line 0\n", str_length=142) at
/usr/home/httpd/src/php-src/main/output.c:704
#4  0x28477fa9 in php_body_write (
str=0x8143154 "\nWarning:  I/O warning : failed to load
external entity \"docbooka/xsl/html/docbook.xsl\" in Unknown on
line 0\n", str_length=142) at
/usr/home/httpd/src/php-src/main/output.c:119
#5  0x2846b6e2 in php_printf (format=0x28502600 "%s\n%s: 
%s in %s on line %d\n%s")
at /usr/home/httpd/src/php-src/main/main.c:400
#6  0x2846c05e in php_error_cb (type=2, error_filename=0x284fba9c
"Unknown", error_lineno=0, format=0x2850223d "%s",
args=0xbfbfe604 "Ã0\024\b\n") at
/usr/home/httpd/src/php-src/main/main.c:736
#7  0x2849f356 in zend_error (type=2, format=0x2850223d "%s") at
/usr/home/httpd/src/php-src/Zend/zend.c:930
#8  0x2835fec4 in php_libxml_internal_error_handler (error_type=0,
ctx=0x0, msg=0x0, ap=0xbfbfe654 "")
at /usr/home/httpd/src/php-src/ext/libxml/libxml.c:351
#9  0x2835ffb0 in php_libxml_error_handler (ctx=0x0, msg=0x287339fb
"%s")
at /usr/home/httpd/src/php-src/ext/libxml/libxml.c:377
#10 0x286a48ab in xmlReportError (err=0x826b580, ctxt=0x826b400,
str=0x8269300 "failed to load external entity
\"docbooka/xsl/html/docbook.xsl\"\n",
channel=0x2835ff98 , data=0x0) at
error.c:381
#11 0x286a4d4b in __xmlRaiseError (schannel=0, channel=0x286a4f3e
, data=0x826b400, ctx=0x826b400, nod=0x0,
domain=8, code=1549, level=XML_ERR_WARNING, file=0x0, line=0,
str1=0x8249a20 "docbooka/xsl/html/docbook.xsl", str2=0x0,
str3=0x0, int1=0, int2=0, msg=0x28724b40 "failed to load external
entity \"%s\"\n") at error.c:573
#12 0x286c2b88 in __xmlLoaderErr (ctx=0x2857ce40, msg=0x28724b40 "failed
to load external entity \"%s\"\n",
filename=0x8249a20 "docbooka/xsl/html/docbook.xsl") at xmlIO.c:426
#13 0x286a69f2 in xmlNewInputFromFile (ctxt=0x826b400,
filename=0x8249a20 "docbooka/xsl/html/docbook.xsl")
at parserInternals.c:1465
#14 0x286c4eed in xmlDefaultExternalEntityLoader (URL=0x82499e0
"docbooka/xsl/html/docbook.xsl", ID=0x0, ctxt=0x826b400)
at xmlIO.c:3176
#15 0x286c4f91 in xmlLoadExternalEntity (URL=0x8249a20
"docbooka/xsl/html/docbook.xsl", ID=0x0, ctxt=0x826b400)
at xmlIO.c:3233
#16 0x286b6f60 in xmlCreateURLParserCtxt (filename=0x826d300
"docbooka/xsl/html/docbook.xsl", options=16398) at parser.c:11039
#17 0x286b7dfe in xmlReadFile (filename=0x826d300
"docbooka/xsl/html/docbook.xsl", encoding=0x0, options=136754176)
at parser.c:12093
#18 0x2899ac0e in xsltParseStylesheetFile (filename=0x826d300
"docbooka/xsl/html/docbook.xsl") at xslt.c:2129
#19 0x2899b110 in xsltLoadStylesheetPI (doc=0x824ca00) at xslt.c:2357
#20 0x28a043ad in transform_run (f=0x8257f60, doc=0x826d300) at
mod_transform.c:182
#21 0x28a044d2 in transform_filter (f=0x8257f60, bb=0x825a120) at
mod_transform.c:249
#22 0x0806d8db in ap_pass_brigade (next=0x2857ce40, bb=0x2857ce40) at
util_filter.c:511
#23 0x0807412b in default_handler (r=0x8256050) at core.c:3513
#24 0x080630be in ap_run_handler (r=0x8256050) at config.c:151
#25 0x08063582 in ap_invoke_handler (r=0x8256050) at config.c:358
#26 0x08060a03 in ap_process_request (r=0x8256050) at http_request.c:246
#27 0x0805c639 in ap_process_http_connection (c=0x8250128) at
http_core.c:253
#28 0x0806b6e2 in ap_run_process_connection (c=0

Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse

2004-04-21 Thread Sterling Hughes 
On Apr 21, 2004, at 2:36 PM, Paul Querna wrote:

The libxml2 Extension in PHP5 uses

xmlSetGenericErrorFunc(NULL, php_libxml_error_handler);

This globally(inside the process) sets the libxml2 error hander to 
PHP's
own function.

Why is this bad?

It clobbers the processing done by anything else that uses libxml2 in
the same process as PHP.
For a simple example, I use mod_transform (
http://svn.outoforder.cc/svn/mod_transform ) with Apache 2 as a filter
to process XML documents w/ XSLT into HTML.  If there are _any_ errors
in the transformation PHP attempts to take care of them.  This causes
Apache to crash because this is not even a PHP request and very quickly
the Error Handler will crash when it tries to get a server context.
This is not an issue isolated to Apache 2.  It could happen in Apache
1.3 if any other module used libxml2.
Nope - it couldn't.  We reset (or we should) the error handler after we 
are done executing.  In processes, only one thing executes at a time, 
and when PHP is executing we want to override this error handler.

The proper way for PHP to handle this is to not set a Generic Error
function, but rather check the return values of libxml2 functions.
Nope.

This is not like the local-mysql vs system-mysql problem that used to 
be
more common.  PHP is initializing libxml2 as if it was the only user,
which is not always the case.

Its actually quite different than that problem.  This is a problem for 
people who use threads.  People who use threads for serving dynamic 
webpages with PHP should be castrated and then shot (well, at least 
castrated, we don't want this problem proliferating.)  The solution 
here is either to use a global context of our own, if libxml2 allows us 
to do so, use a mutex, or just laugh very hard and very loud when 
people tell us they have a problem using php in threaded environments.  
On that note

bwahhhahahahhahahaha.

-Sterling

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] xmlSetGenericErrorFunc Abuse

2004-04-21 Thread Paul Querna 
The libxml2 Extension in PHP5 uses 

xmlSetGenericErrorFunc(NULL, php_libxml_error_handler);

This globally(inside the process) sets the libxml2 error hander to PHP's
own function.

Why is this bad?

It clobbers the processing done by anything else that uses libxml2 in
the same process as PHP.

For a simple example, I use mod_transform (
http://svn.outoforder.cc/svn/mod_transform ) with Apache 2 as a filter
to process XML documents w/ XSLT into HTML.  If there are _any_ errors
in the transformation PHP attempts to take care of them.  This causes
Apache to crash because this is not even a PHP request and very quickly
the Error Handler will crash when it tries to get a server context.

This is not an issue isolated to Apache 2.  It could happen in Apache
1.3 if any other module used libxml2.

The proper way for PHP to handle this is to not set a Generic Error
function, but rather check the return values of libxml2 functions.

This is not like the local-mysql vs system-mysql problem that used to be
more common.  PHP is initializing libxml2 as if it was the only user,
which is not always the case.

I believe this is something that should be fixed before 5.0 is released.

Thanks,
Paul Querna


signature.asc
Description: This is a digitally signed message part