On 13/01/07, Marvin Humphrey <[EMAIL PROTECTED]> wrote:
It's been a couple days with no response to this, so it looks like
I've been Warnocked. Not too surprising, as this very small memory
leak affects very few people: people using Valgrind to debug XS
modules, possibly people embedding Perl.
Since there doesn't seem to be a burning need to fix this, here's a
"do no harm" patch which just adds a note to perlhack.pod:
Thanks, I applied this as change #29803. I suppose that if DynaLoader
doesn't unload all by default, it's for speed of interpreter shutdown.
However having that option available only at compile time is a pain.
Couldn't it be overriden by an environment variable, for example ?
--- pod/perlhack.pod.old 2007-01-13 08:44:41.000000000 -0800
+++ pod/perlhack.pod 2007-01-13 10:08:20.000000000 -0800
@@ -2915,6 +2915,10 @@
is a good sign of these. Fixing these leaks is non-trivial,
unfortunately, but they must be fixed eventually.
+B<NOTE 4>: L<DynaLoader> will not clean up after itself completely
+unless Perl is built with the Configure option
+C<-Accflags=-DDL_UNLOAD_ALL_AT_EXIT>.
+
=head2 Rational Software's Purify
Purify is a commercial tool that is helpful in identifying
I've also isolated the other leak. It can be reduced down to this:
local *Foo::stuff = *Bar::ISA;
local @Foo::stuff = 0 .. 10;
It manifests when running that "XSLeaker" module I supplied when
these lines in XSLoader are accessed:
local *DynaLoader::isa = *{"$module\::ISA"};
local @DynaLoader::isa = (@DynaLoader::isa, 'DynaLoader');
It seems that the glob copy has to use ISA. This doesn't leak:
@Bar::things = qw( a b c );
local *Foo::stuff = *Bar::things;
local @Foo::stuff = 0 .. 10;
I don't know what to make of that. I can try to come up with a patch
for XSLoader, but this seems like a more general problem. Thoughts?
Yes, indeed (ISA being special) -- thanks for that detective work,
that should help in fixing that leak.
