Re: [Log4cpp-devel] log4cpp shutdown and memory leaks

[Bastiaan B. <bas...@li...>]

On Tue, 2003-04-22 at 21:58, Jon Stewart wrote:
> Quoth Bastiaan:
> > * in general cleaning up at program exit looks nice but is a waste of
> > resources (all remaining memory is going to be freed by the OS anyway).
> > OTOH it's nice if the application programmer can choose for herself, for
> > valgrinding,etc. .
> 
> With all due respect -- I find log4cpp an invaluable tool for hunting down
> race conditions -- I must disagree with this statement. I've been fairly
> troubled troubled by log4cpp's memory leaks.
> 

double plus troubled, that's bad ;-)

> Aesthetically/morally, C++ dictates that thou shalt delete thine memory. Not

Not to be nitpicking, but it does not per se . You're perfectly free to
leave that to a garbage collector for example. Using one would put an
end to so much waisting time with memory administrivia. Unfortunately it
is not an option of a library like log4cpp to force that upon the
application programmer.

> to do so is a bug. That's my brand of religion and I'm sticking to it.

I would want to interfere with your religious beliefs :-)

> But it's an ecumenical world, and I don't want to get into a religious war.
> So, my *pragmatic* reason for being troubled by this sentiment (one I also
> had to deal with from a former coworker) is that these static memory leaks
> mask a user's own memory leaks. Visual Studio now tells you, somewhat

One way in which the static leaks differ from the dynamic ones, is that
the latter grow over time, automically making themselves the center of
attention with a decent leak checker.

> unhelpfully, about memory leaks at process shutdown. All kind of tools, like
> Purify and Boundschecker, also do this job (in a much better way). When one
> is trying to use these tools to enforce a strict policy of no memory leaks
> in the repository, it's very difficult to separate one's own memory leaks
> from third party memory leaks. That's a good policy to have, as C++ is a
> systems language and systems typcially can't afford to have memory leaks; if
> you can kill memory leaks from the start, you're going to have a better
> chance of shipping. It would be extremely nice if log4cpp accomodated that
> policy.
> 

Yes, it would. It just hasn't been a priority (for me), since the
services in which I use log4cpp are based on omniORB, which until
recently couldn't cleanup properly at exit time. 
One reason for my remark (other than to camouflage that I've been too
lazy to work on the problem) is that I feel that it's a minor problem
compared to other things in log4cpp that may need attention, e.g.:
* finish multithreading support. Currently it's half baked in half of
the classes.
* Define a clean separation between API, SPI and internal stuff.
* Improve documentation
* Improve build settings (e.g. proper multithreading flags for g++ 3.x)
* make PropertyConfigurator extensible for third party Appenders, etc.
* interoperability with log4j's SocketAppender (in both directions)  

> As far as implementation goes, when a number of logical singletons exist
> with dependencies between them, I generally prefer wrapping them in a
> "singleton context". That is, create one singleton class who's sole purpose
> is to create, destroy, and provide access to a system's logical singletons.
> One can then construct this singleton context and throw it into a static
> boost::scoped_ptr and be assured that everything will be taken care of at
> the appropriate time.
> 

Yes, but also all references to log Categories need to be taken into
account, since the destructors of static objects may want to log as
well. So I guess all Category& occurences need to be replaced with
boost::shared_ptr's or similar.
That's not a trivial change..... but for 0.4.x it should be OK. 


> I just got laid off. I've got a lot of work to do finding a new job, but I'd

Sorry to hear that.

> be happy to work on this problem with someone else (Dirk?).
> 

Great! 
Since you mentioned boost::scoped_ptr I guess you have experience with
boost? I would like to use it in log4cpp but have no experience in
integrating it in a project (autoconf detection, compiler settings,
etc.)

Regards,

Bastiaan


> My $.02.
> 
> 
> Jon
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel