On Jan 10, 2007, at 2:45 PM, Marvin Humphrey wrote:
However, before I do that, I'd like to know whether
DL_UNLOAD_ALL_AT_EXIT should be defined more often. Should
DEBUGGING turn it on? If so then there's no need to patch
perlhack. Or should it be on all the time? IIUC, not cleaning up
@dl_librefs will cause an ongoing leak in situations where multiple
Perl interpreters come and go.
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:
--- 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?
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
