Hi Wez,
I found a bad code in ext/libxml.
On each request startup/shutdown it changing some libxml callbacks.
At first this slowdown each request, at second multi-threaded PHP may fail,
because different threads may set/clean the same callbacks in the same time.
May be it is possible to setup these callbacks forever in MINIT/MSHUTDOWN,
set some flag (somthing like LIBXML(in_request)) in RINIT/RSHUTDOWN, and
check it in callbacks.
Thanks. Dmitry.
Dmitry Stogov wrote:
Hi Wez,
I found a bad code in ext/libxml.
On each request startup/shutdown it changing some libxml callbacks.
At first this slowdown each request, at second multi-threaded PHP may fail,
because different threads may set/clean the same callbacks in the same time.May be it is possible to setup these callbacks forever in MINIT/MSHUTDOWN,
set some flag (somthing like LIBXML(in_request)) in RINIT/RSHUTDOWN, and
check it in callbacks.
Which ones in particular?
Each of the callbacks being utilized are thread safe.
The reason why they need to be set per request is in order to play nice
with any other modules that might be loaded and use libxml2.
for example: prior to how the current callbacks are implemented it was
possible to blow away PHP stream usage by any of the xml extensions
using mod_perl and its xsl module (could do this whether or not PHP was
running threaded).
There are also many other ways to screw with the libxml2 globals and
effect PHP extensions based on libxml2 as well using other modules so
the only way to protect them is on each request. In short putting them
into the MINIT/MSHUTDOWN will open security holes.
Rob
Sounds like a nasty situation.
I don't think it's possible to sanely restore the handlers at
rshutdown in a threaded build without screwing up the other threads
that are currently executing.
My suggestion is to not restore the handlers for threaded builds, and
if there is a library sharing/abuse issue, then treat it as an
installation/configuration problem for the person deploying it (eg:
don't do that!). There's not much you can do about that without
rewriting libxml2 to not use globals for the callbacks. :-/
--Wez.
Dmitry Stogov wrote:
Hi Wez,
I found a bad code in ext/libxml.
On each request startup/shutdown it changing some libxml callbacks.
At first this slowdown each request, at second multi-threaded PHP may fail,
because different threads may set/clean the same callbacks in the same time.May be it is possible to setup these callbacks forever in MINIT/MSHUTDOWN,
set some flag (somthing like LIBXML(in_request)) in RINIT/RSHUTDOWN, and
check it in callbacks.Which ones in particular?
Each of the callbacks being utilized are thread safe.
The reason why they need to be set per request is in order to play nice
with any other modules that might be loaded and use libxml2.for example: prior to how the current callbacks are implemented it was
possible to blow away PHP stream usage by any of the xml extensions
using mod_perl and its xsl module (could do this whether or not PHP was
running threaded).
There are also many other ways to screw with the libxml2 globals and
effect PHP extensions based on libxml2 as well using other modules so
the only way to protect them is on each request. In short putting them
into the MINIT/MSHUTDOWN will open security holes.Rob
I don't think I made myself clear on the globals. The only situation
there would be a problem is if PHP were built threaded and libxml2 were
not (which as of 2.5.8 it is built threaded by default).
When running threaded, each thread has its own global state, so when
modified at request startup/shutdown the global is only changed for that
thread, rather than being set at the module startup/shutdown which would
set the default values used to initialize the global states of the threads.
Rob
Wez Furlong wrote:
Sounds like a nasty situation.
I don't think it's possible to sanely restore the handlers at
rshutdown in a threaded build without screwing up the other threads
that are currently executing.My suggestion is to not restore the handlers for threaded builds, and
if there is a library sharing/abuse issue, then treat it as an
installation/configuration problem for the person deploying it (eg:
don't do that!). There's not much you can do about that without
rewriting libxml2 to not use globals for the callbacks. :-/