logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Steiner <peter.stei...@hugwi.ch>
Subject Leak in apr_pools when using RollingFileAppender
Date Wed, 04 Oct 2006 09:44:51 GMT
I'm using the SVN version of log4cxx (with a patched
propertyconfigurator, see http://issues.apache.org/jira/browse/LOGCXX-102).

I have observed that our application increases its working set in 8k
steps. I have tracked it down to happen whenever the log file rolls over:

log4cxx::rolling::RollingFileAppender::rollover() (Line 153) calls
WriterAppender::closeWriter() which allocates a new APR pool.

I think the error ultimately is in allocator_free() in apr_pools.c and
was already discussed by Brian Pane in dev@httpd.apache.org (see
for the message). I couldn't find any correction for this in the APR
trunk, however.

In my case I have observed when stepping through the code that after the
allocation of the pool in WriterAppender::closeWriter(), the next call
to allocator_free() comes from a FileOutputStream destructor and only
after that the pool from closeWriter is freed.

The second call to allocator_free has a current_free_index of
(unsigned)-1 and then overwrites the node pointer in allocator->free, so
that the first of these nodes will never be freed.

That said I'm not sure if it makes sense that closeWriter allocates its
own pool. Reading
I ask myself if closeWriter should not take a pool parameter (like
rollover already does) instead of having its own.

Regards, Peter
    _   _        Peter Steiner <peter.steiner@hugwi.ch>
  / /_/ /        Hug-Witschi AG <http://www.hugwi.ch/>
 /  _  /         Electronic Engineering
/_/ /_/  _   _   Auriedstrasse 10
   / / / / / /   CH-3178 Boesingen
  / /_/ /_/ /    Tel  +41 31 740 44 44
 /_ _ _ _ _/     Fax  +41 31 740 44 45

View raw message