On Feb 18, 2008, at 6:53 AM, Tomislav Petrović wrote:
I'm fresh user of log4cxx. Recently one of the larger projects
in firm landed into my lap which uses log4cxx extensively, and
crashes on customer site (our internal testing newer caught this :()
due to following:
I have a class which has private log4cxx::LoggerPtr.
In constructor it is initialized like:
MyClass()
: logger(log4cxx::Logger::getLogger("someName"))
{
...
}
Then it is used extensively in some other parts of code and in
destructor it is set to NULL.
Program crashes because at some point logger becomes NULL, actually
operator-> method called on logger returns NULL. Since LOG4CXX_DEBUG
macro does logger->isDebugEnabled() this crashes due to NULL pointer
exception.
My question is which method called external to my class can make
logger (actually its underlying pointer) become NULL?
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.
I hope I managed to explain my problem, any help is appreciated.
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.
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.
