logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: log4cxx::LoggerPtr becoming NULL
Date Mon, 18 Feb 2008 16:47:37 GMT

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.
Mime
View raw message