logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomislav Petrović <t.petro...@inet.hr>
Subject Re: log4cxx::LoggerPtr becoming NULL
Date Tue, 19 Feb 2008 08:07:32 GMT
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")

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. :(

Tomy <t.petrovic@inet.hr>

View raw message