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 http://mail-archives.apache.org/mod_mbox/httpd-dev/200512.mbox/[EMAIL PROTECTED] 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 http://svn.apache.org/viewvc/apr/apr/trunk/docs/pool-design.html?view=co I ask myself if closeWriter should not take a pool parameter (like rollover already does) instead of having its own. Regards, Peter -- _ _ Peter Steiner <[EMAIL PROTECTED]> / /_/ / 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
