Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9488
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <020a01c42862$9fcec210$f7dea8c0@cyberware.local>
References: <1082583400.12577.19.camel@powah.cc.force-elite.com> <1CA1D9B6-93F7-11D8-9EC0-000A95E073A0@php.net> <1082596603.15932.5.camel@powah.cc.force-elite.com> <D39D5842-941A-11D8-9EC0-000A95E073A0@php.net> <020a01c42862$9fcec210$f7dea8c0@cyberware.local>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <06E7C5C7-947C-11D8-9086-000A95E073A0@php.net>
Content-Transfer-Encoding: 7bit
Cc: "Paul Querna" <chip@force-elite.com>, <internals@lists.php.net>
Date: Thu, 22 Apr 2004 09:42:22 -0700
To: "Rob Richards" <rrichards@ctindustries.net>
Subject: Re: [PHP-DEV] xmlSetGenericErrorFunc Abuse
From: sterling@php.net (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