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
