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 <[EMAIL PROTECTED]>
