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