logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: log4cxx::LoggerPtr becoming NULL
Date Tue, 19 Feb 2008 17:48:21 GMT

On Feb 19, 2008, at 5:08 AM, Tomislav Petrović wrote:

> Curt Arnold said on 19.2.2008 10:15:
>
> First of all, many many thanks for your prompt responses.
>
>> On Feb 19, 2008, at 2:07 AM, Tomislav Petrović wrote:
>>> Unfortunately it is not that simple :). MyClass instance is very  
>>> much
>>> alive :(.
>>> Inside one of the MyClass methods, for example I have code like  
>>> this:
>>>
>>> LOG4CXX_DEBUG(logger, "log something")
>>> simple statement (or few statements) which does not do anything  
>>> with logger
>>> LOG4CXX_DEBUG(logger, "log something else")
>> Is "logger" a static class member, class member, or an local  
>> variable?  You said in your other message that would might be  
>> calling Logger::getLogger() from many threads which would not be  
>> the case if you were using a static class member.
>
> logger is a class member being initialized with Logger::getLogger()  
> in some initialization method of class, this initialization method  
> is called for each class instance once in separate thread so there  
> is possibility that two instances have their initialization methods  
> called
> simultaneously.
>


I don't see a mechanism for a fault in Logger::getLogger() to affect  
an already initialized LoggerPtr.  If you are initializing logger in  
an initialization method per instance, then there is the possibility  
that the initialization method has been skipped.  You could move the  
initialization back into the object constructor to make sure there is  
not a path to attempt to use logger before it is initialized, though  
it would be better to push it back even further and make it a static  
member.


> So since we are using revision 474761 (sorry missed last 1 in first  
> post), is it possible this is related to https://issues.apache.org/jira/browse/LOGCXX-132?

>  In which revision where problems described there fixed?


According to the Subversion Commits page on the bug, the last commit  
against the bug was rev 407850.  So it looks like you have all the  
LOGCXX-132 fixes.
>
>
>
>> Don't know how cooperative your client is, but having someone being  
>> able to reproduce the problem is key to figuring out how to avoid  
>> it.  Some possible experiments would be:
>> 1. Attempt to substantially reduce or  eliminate calls to  
>> Logger::getLogger() on non-main threads and see if the problem goes  
>> away.
>> 2. Update to SVN HEAD and see if the problem goes away.
>> 3. Fabricate a test case that mimics the logging behavior of the  
>> application and attach to a bug report.  If the code can run or  
>> easily be ported to Linux, I could run it under helgrind to check  
>> for synchronization issues.  It would also be be useful to know:  
>> does the code fail on the client's machine with your snapshot of  
>> log4cxx and does it fail when built with the current head.
>
> Code fails on client machine with our snapshot (revision 474761).
>
> I'll think about all of those possibilities and see which I can try  
> with the client, thanks.
>



Another possibility would be to change the definitions of the  
LOG4CXX_level macros in logger.h et al to check for null-ness before  
checked isEnabledFor.  That is a design inherited from log4j and log4j  
would throw a NPE if you attempted to log on a null logger.  You'd  
lose logging, if it was only a log4cxx issue, then that might be  
acceptible.

If you are seeing in one straight code path the logger go from non- 
null to null, perhaps another thread has deleted you in the interim.   
I'd expect that if that happened, if you got past the logging  
statement something else would quickly blow up


Mime
View raw message