# xmlSetGenericErrorFunc Abuse
- Thread: https://externals.io/message/9471
- Original archive: https://news-web.php.net/php.internals/9471
- Started by Paul Querna on 2004-04-21T21:36:40+00:00
- Messages: 9
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #9471 — Paul Querna — 2004-04-21T21:36:40+00:00
URL: https://externals.io/message/9471#9471
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
---
## #9476 — Sterling Hughes — 2004-04-22T00:50:55+00:00
URL: https://externals.io/message/9471#9476 · In reply to: #9471
> 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
---
## #9477 — Paul Querna — 2004-04-22T01:16:43+00:00
URL: https://externals.io/message/9471#9477 · In reply to: #9476
> 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=0x8250128) at
connection.c:42
#29 0x08061c57 in child_main (child_num_arg=0) at prefork.c:623
#30 0x08061d47 in make_child (s=0x8099db8, slot=0) at prefork.c:663
#31 0x0806256c in ap_mpm_run (_pconf=0x8098018, plog=0x80c2018,
s=0x8099db8) at prefork.c:937
#32 0x08067633 in main (argc=2, argv=0xbfbfebe8) at main.c:665
#33 0x0805c1c8 in _start (ap=0xbfbfecec
"/usr/home/httpd/local/bin/httpd") at
/usr/src/lib/csu/i386-elf/crt1.c:104
> 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....
>
Please don't be so quick to judge.
Thanks,
-Paul Querna
> bwahhhahahahhahahaha.
>
> -Sterling
---
## #9479 — Sterling Hughes — 2004-04-22T05:06:34+00:00
URL: https://externals.io/message/9471#9479 · In reply to: #9477
>
> > […]
>
> 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=0x8250128) at
> connection.c:42
> #29 0x08061c57 in child_main (child_num_arg=0) at prefork.c:623
> #30 0x08061d47 in make_child (s=0x8099db8, slot=0) at prefork.c:663
> #31 0x0806256c in ap_mpm_run (_pconf=0x8098018, plog=0x80c2018,
> s=0x8099db8) at prefork.c:937
> #32 0x08067633 in main (argc=2, argv=0xbfbfebe8) at main.c:665
> #33 0x0805c1c8 in _start (ap=0xbfbfecec
> "/usr/home/httpd/local/bin/httpd") at
> /usr/src/lib/csu/i386-elf/crt1.c:104
>
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
---
## #9480 — Paul Querna — 2004-04-22T05:35:19+00:00
URL: https://externals.io/message/9471#9480 · In reply to: #9479
> 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
---
## #9485 — Rob Richards — 2004-04-22T12:09:11+00:00
URL: https://externals.io/message/9471#9485 · In reply to: #9479
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
---
## #9488 — Sterling Hughes — 2004-04-22T16:42:22+00:00
URL: https://externals.io/message/9471#9488 · In reply to: #9485
> From: Sterling Hughes
>
>
> > […]
>
> 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
---
## #9490 — Rob Richards — 2004-04-22T18:23:57+00:00
URL: https://externals.io/message/9471#9490 · In reply to: #9488
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
---
## #9496 — Andi Gutmans — 2004-04-23T13:57:23+00:00
URL: https://externals.io/message/9471#9496 · In reply to: #9488
At 02:23 PM 4/22/2004 -0400, Rob Richards wrote:
>From: Sterling Hughes
>
> > […]
>
>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