httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 45288] New: libapr memory leak issue
Date Thu, 26 Jun 2008 15:03:16 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=45288

           Summary: libapr memory leak issue
           Product: Apache httpd-2
           Version: 2.0.63
          Platform: Other
        OS/Version: Windows Server 2003
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Other Modules
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: anne.chanthabouasy@sun.com


One of our customers encountered an issue with our Sun Policy Agent, installed
on apache 2.0.63 for Windows Server 2003. After a deep investigation, our
technical experts show that the issue is in libapr.dll :
debug diagnostic tool output 
------------------------------------------------
libapr.dll is responsible for 797,18 MBytes worth of outstanding 
allocations. The following are the top 2 memory consuming functions:

libapr!apr_palloc+14a: 741,34 MBytes worth of outstanding allocations.

libapr!apr_pool_create_ex+de: 34,12 MBytes worth of outstanding 
allocations. If this is unexpected, please contact the vendor of this 
module, Apache Software Foundation, for further assistance with this 
issue.   Warning WARNING - DebugDiag was not able to locate debug 
symbols for mswsock.dll, so the reported function name(s) may not be 
accurate

mswsock.dll is responsible for 2,08 MBytes worth of outstanding 
allocations. The following are the top 2 memory consuming functions:

mswsock+6fb0: 2,00 MBytes worth of outstanding allocations.

mswsock+47c0: 79,53 KBytes worth of outstanding allocations. If this is 
unexpected, please contact the vendor of this module, Microsoft 
Corporation, for further assistance with this issue.   Warning Detected 
symptoms of high fragmentation in the following heaps in 
Apache.exe__PID__14624__Date__04_28_2008__Time_03_04_01PM__748__Manual 
Dump.dmp


0x00250000 (msvcrt!adjust_fdiv+860 - 96,55% Fragmented) Heap 
fragmentation is often caused by one of the following two reasons

1. Small heap memory blocks that are leaked (allocated but never freed) 
over time

2. Mixing long lived small allocations with short lived long allocations

Both of these reasons can prevent the NT heap manager from using free 
memory effeciently since they are spread as small fragments that cannot 
be used as a single large allocation

----------
to be sure, some tests have been made with and without our Agent.It seems like
the freeing of the memory allocated through ap_calloc (or the destruction of
the mem pool) is not implemented properly in Apache ( as it clearly indicated
leaks without agent ). 

-------------------Without Agent-------------------

libapr.dll is responsible for 199,80 MBytes worth of outstanding allocations.
The following are the top 2 memory consuming functions:
libapr!apr_palloc+14a: 189,43 MBytes worth of outstanding allocations.
libapr!apr_allocator_alloc+11d: 10,14 MBytes worth of outstanding allocations.
If this is unexpected, please contact the vendor of this module, Apache
Software Foundation, for further assistance with this issue.
libeay32.dll is responsible for 2,14 KBytes worth of outstanding allocations.
The following are the top 2 memory consuming functions:
libeay32!OpenSSLDie+3b: 2,14 KBytes worth of outstanding allocations. If this
is unexpected, please contact the vendor of this module for further assistance
with this issue.

  Warning Detected symptoms of high fragmentation in the following heaps in
Apache.exe__PID__12412__Date__04_25_2008__Time_02_08_26PM__994__Manual Dump.dmp
0x00250000 (msvcrt!adjust_fdiv+860 - 87,30% Fragmented)
0x27090000 (LeakTrack!g_hLTHeap - 93,28% Fragmented) Heap fragmentation is
often caused by one of the following two reasons

1. Small heap memory blocks that are leaked (allocated but never freed) over
time
2. Mixing long lived small allocations with short lived long allocations

Both of these reasons can prevent the NT heap manager from using free memory
effeciently since they are spread as small fragments that cannot be used as a
single large allocation
-------------without agent ------------------------------


**************************** with Agent ***************************

libapr.dll is responsible for 614,28 MBytes worth of outstanding allocations.
The following are the top 2 memory consuming functions:
libapr!apr_palloc+14a: 566,31 MBytes worth of outstanding allocations.
libapr!apr_pool_create_ex+de: 33,59 MBytes worth of outstanding allocations. If
this is unexpected, please contact the vendor of this module, Apache Software
Foundation, for further assistance with this issue.

mswsock.dll is responsible for 2,09 MBytes worth of outstanding allocations.
The following are the top 2 memory consuming functions:
mswsock+6fb0: 2,02 MBytes worth of outstanding allocations.
mswsock+47c0: 70,31 KBytes worth of outstanding allocations. If this is
unexpected, please contact the vendor of this module, Microsoft Corporation,
for further assistance with this issue.   Information DebugDiag did not detect
any known native heap(unmanaged) problems in
Apache.exe__PID__11600__Date__04_24_2008__Time_04_20_24PM__49__Manual Dump.dmp
using the current set of scripts.

**************************** with Agent *************************** 

At least, There is the analysis from our Access Manager Sustaining who worked
on this issue :
----------------------------- email thread regarding this issue
-------------------------

After looking at the docs and doing some tests, here is what I found:

"The agent is not creating any pool. It is only using the Apache pools, and it
cannot clean them. The only thing I found that could be tried is to use the
apr_allocator_max_free_set() function to specify an upper limit on the pool. I
run a test by limiting the size to 32 (value recommended in the doc) for the
request pool, but didn't see any noticeable difference. There was a difference
of about 500 K in the memory usage, but this is too small to be significant.
The memory was not released after I stopped the users.

The memory report shows that it is the libapr.dll library that is leaking,.
therefore the amsdk is not responsible for the leak. And in the apache agent
all the memory allocation is done in the request pool managed by Apache. As a
conclusion I don't think that there is anything that can be done at the agent
level to fix this problem. Apache is doing a lot of allocation on its own as it
is shown in the test without the agent, so even if the agent is not allocating
memory in the pool anymore, there will still be a memory increase. "


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message