https://issues.apache.org/bugzilla/show_bug.cgi?id=47449
Summary: mod_mem_cache 2.0 memory leak
Product: Apache httpd-2
Version: 2.0-HEAD
Platform: All
OS/Version: All
Status: NEW
Keywords: PatchAvailable
Severity: normal
Priority: P2
Component: Other Modules
AssignedTo: [email protected]
ReportedBy: [email protected]
Created an attachment (id=23900)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23900)
Fix memory leak in 2.0 mod_mem_cache
In 2.0.x, mod_mem_cache has a memory leak. The attached patch
corrects it.
The problem doesn't happen in 2.2 or trunk, since mod_mem_cache's
memory management was completely re-written for 2.2.
The leak occurs when a cache entry expires, the cache determines that
it is still valid, and updates the headers saved in the cache entry.
The previously saved headers are never freed.
Simply adding free() calls before saving the new headers resulted in
instability under load, as other threads might still be accessing the
older saved headers. The patch looks at the reference count, and if
it might not be safe to free the old headers yet, remembers the
pointers to free them later.
Some alternative approaches would have been to use a process-wide lock
to make sure no other thread could access the entry at the same time,
but that would likely have had terrible effects on performance. Or a
per-cache-entry lock might have been used, but managing those would
require a pool for each cache entry, and by the time that was all
done, we'd be half-way to the 2.2 code anyway.
I've run this for hours, and a slightly earlier version for
days, under the same load that originally reproduced the memory leak
and then the instability with the simple fix.
I don't know if mod_mem_cache in 2.0 is used widely enough to warrant
fixing this. I'd rather just move to 2.2 myself, but couldn't in this
case. But I wanted to at least provide the patch, in case someone
else is running into the problem.
--
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: [email protected]
For additional commands, e-mail: [email protected]
