Since a few people have asked what the leak in AxKit was, I've now setup
the archive so people can go and read...
On Fri, 15 Sep 2000, Wilt, Paul wrote:
I would like to see how you traced down your memory leak and what the final
root cause turned out to be!
It does now [matt sets up the archive...]
http://axkit.org/cgi-bin/ezmlm-cgi/4
See "Phew- thats a lot of updates!".
For anyone interested in how I debugged it, the exception handling
initiative was absolutely fundamental to this, although I'm thinking of
re-writing the guide section a bit to cover everything that I've changed
my mind about while debugging this. Anyway, I found the second mentioned
leak in the "Phew" message by creating a new mod_perl handler class that
emulated AxKit's minimum path (which just returned DECLINED), which I knew
to be leaking. Gradually I added in some code from AxKit until the leak
showed up. That was the push @_, "\n" bug.
The second one was the worst leak - it seemed to leak memory
exponentially - it would remain stable for about 300 hits, and then
suddenly go absolutely out of control leaking about 50k a hit, then 100k a
hit, until I had a 200M mod_perl process eating nothng but swap. To find
this was where exceptions came in. Once I'd gotten rid of the Debug memory
leak I could then add in a throw Declined(reason = "mem test") anywhere
in the code. This would simply return DECLINED. I moved it further and
further into the code, until it passed the point where it started leaking,
then I had to follow that stepping into the function. And this is where
exceptions are really cool - I don't need to change the method to get
right out to the exception handler - no multiple return() statements to
cope with, just throw the exception and you're out of the code. So anyway,
it turned out that the leak occurs in this code which I use to send
Gzipped results to the browser, ripped straight from Apache::GzipChain:
# AxKit::Debug(5, 'Getting Vary header');
# my @vary = $r-header_out('Vary') if $r-header_out('Vary');
# push @vary, "Accept-Encoding", "User-Agent";
# AxKit::Debug(5, 'Setting Vary header');
# $r-header_out('Vary',
# join ", ",
# @vary
# );
(excuse the fact that its commented out).
Once I removed that the leak was gone.
The final one, which was even trickier to find, was DIR_MERGE (part of
mod_perl's custom config directives code). I had suspected it might leak a
bit, and my suspicions are now confirmed. I'll let Doug deal with that
one.
Its been an exhausting week trying to find this and do real work at the
same time too! Unfortunately it has set back the CMS quite severely and it
won't be ready in time for ApacheCon, so no demo for that I'm afraid...
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
