Jim Gallacher <[EMAIL PROTECTED]> writes:
>>>Furthermore, you can't depend on the request object being valid once
>>>the request processing has completed. At some point request_tp_clear (in
>>>requestobject.c) will get called and request->server will be set to
>>>NULL. (At least I think this is correct). My gut tells me you'll get
>>>some random seg faults.
>
> My gut was right. Your current version segfaults (using mpm-prefork). It
> might work if you register a cleanup to remove the reference to your
> logging handler (untested):
>
> req.register_cleanup(log.removeHandler, hdlr)
>
> The problem here is that we are depending on the user to add that line
> to their code to avoid the segfault. I don't like the idea of including
> code in mod_python which may result in a segfault, even if the user is
> warned of the dangers in the docs.
Ok. I found the problem too... I was going to add an end of request
clean up to make logging rather like resource usage:
def handler(http):
hdlr = apache_log_handler.ApacheLogHandler(http)
logging.getLogger().addHandler(hdlr)
logger = logging.getLogger("webapp")
.
.
.
hdlr.end()
return apache.OK
But I guess I ought to try and find some way of checking the validity
of the request object.
> Loggers have module level scope. When you add a handler you are adding
> it to logging.root. In a given process, each call to
> log.addHandler(hdlr) adds another ApacheLogHandler instance with it's
> associated request object. Thus you would expect that when you try to
> log an error you would see multiple messages in the apache log, but
> mod_python actually segfaults instead, since most request objects
> (except the current one) are likely invalid. Thus the need to remove the
> handler at the end of the request as mentioned above.
>
>> 2. the logging record doesn't get flushed before the request has
>> completed so that when it is flushed the correct state is no longer
>> available.
>>
>> This is also possible, clearly it would be a bug because the
>> logging record should be flushed immediately (if that's the
>> implementation of the handler)
>
> The problem is not with the current request. That will be ok as long as
> you are logging your message prior to the end of the request processing
> phase. The problem is with the references to old requests being held by
> logging.root.
You can always treat it as a resource, like a database connection that
has to be obtained and specifically thrown away.
> Just to be clear Nic, I'm not fighting you on the *idea* of including
> your ApacheLogHandler - I may even be in favour of it. I'm just pointing
> out some potential problems. I have a few more up my sleeve but I want
> to test them before commenting.
Got it. I was just getting grumpy.
I'll see what I can do about making these problems go away.
Nic
