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 09:15:22 GMT

On Feb 19, 2008, at 2:07 AM, Tomislav Petrović wrote:

> Curt Arnold said on 18.2.2008 17:47:
>> That should not happen unless other code intentionally bypasses the  
>> enforcement of the private visibility.  log4cxx does not maintain  
>> any list of LoggerPtr's or push changes out to them.  The only way  
>> that a LoggerPtr should become null would be if some code outside  
>> of log4cxx set it or if the LoggerPtr was destructed.
> OK, thanks for the info.
>> I think it is more likely that an instance of MyClass is used after  
>> destruction.  Something like:
>> MyClass* instance = new MyClass();
>> delete instance;
>> instance->doSomething();
>> could trigger the issue.
> 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.

> And during its execution first LOG4CXX_DEBUG passes ok, and second  
> one crashes. After examining crash dump and the dissasembly around  
> statements when it crashed this happens (roughly speaking).
> Method operator-> is called on logger, it returns NULL and  
> isDebugEnabled is called on this NULL and this crashes.
> As I said above what puzzles me is that first call to function with  
> identical code (just the string logged is different) passes ok.
> Has anything similar been reported before against log4cxx since we  
> are using older SVN trunk version (i think is it revision 47476)???
> A bit more info is that this doesn't happen on any of our testing  
> systems but happens on customer production machine. The only thing  
> this machine has and our testing machines don't is 8 (16 virtual  
> ones) processors (our testing ones have two at the most - 4 virtual).
>> If you are running on Linux, I'd suggest running your application  
>> under Valgrind and see if it reports anything suspicious.  If other  
>> platforms, then something like Purify or BoundsChecker might help  
>> identify the problem.
> I'm on Windows, we have tried BoundsChecker, nothing suspicious  
> except one memory leak has been discovered. :(

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  
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.
View raw message