Uploaded image for project: 'Log4cxx'
  1. Log4cxx
  2. LOGCXX-161

Using RollingFileAppender increases the working set with each rollover

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.10.0
    • Fix Version/s: 0.10.0
    • Component/s: Appender
    • Labels:
      None

      Description

      There seems to be a memory leak in APR 1.2.7 (see http://issues.apache.org/bugzilla/show_bug.cgi?id=40955) which can be reproduced using RollingFileAppenders:

      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. Before this pool is freed, a call
      to allocator_free() comes from a FileOutputStream destructor, followed by the allocator_free() call for the closeWriter pool. Because of the above APR bug, only one of these pools is deallocated...

      Perusing the guide lines for APR pools (http://svn.apache.org/viewvc/apr/apr/trunk/docs/pool-design.html?view=co), I suppose that closeWriter doesn't need its own pool ("Objects should not have their own pools."). When I changed the log4cxx source accordingly, I couldn't reproduce the leak anymore. (UPDATE: that's not true)

        Attachments

        1. log4cxx-161.patch
          2 kB
          Peter Steiner
        2. log4cxx-161-mutex.patch
          2 kB
          Peter Steiner
        3. log4cxx-161-threshold.patch
          2 kB
          Peter Steiner

          Activity

            People

            • Assignee:
              carnold@apache.org Curt Arnold
              Reporter:
              pesche Peter Steiner
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: