On Jan 8, 2007, at 11:30 AM, Dan Sully wrote:
* Marvin Humphrey shaped the electrons to say...
I think you'll need to look elsewhere. Coincidentally, I'm
debugging memory leaks right this moment using valgrind. If you
have access to a Linux system, I'd strongly recommend you give it
a try.
Any suggestions for using valgrind with Perl/XS?
First, it only works on Linux, AFAICT. FreeBSD valgrind crashes
outright with Perl.
Once you have valgrind installed, getting started is easy: you just
wrap a test script on the command line.
However, you'll get less noise if you compile a debugging perl for
yourself, then set the environment variable PERL_DESTRUCT_LEVEL to 2.
$ PERL_DESTRUCT_LEVEL=2
$ export PERL_DESTRUCT_LEVEL
$ ./Build code; valgrind --leak-check=full /usr/local/debugperl/bin/
perl5.8.8 -Mblib t/021-dyn_virtual_table.t
There's some documentation on this in perlhack:
http://perldoc.perl.org/perlhack.html#valgrind
http://perldoc.perl.org/perlhack.html#PERL_DESTRUCT_LEVEL
Valgrind's output is often easy to interpret, occasionally not so
easy. I used to use Perl's memory management tools a lot, but I
found that leaks within my XS/C code were easier to isolate under an
independent malloc.
Unfortunately, I've never succeeded in banishing all of Perl's leaks
when debugging XS under either 5.8.8 or 5.9.4. Now that we're having
this discussion, I will attempt to write up a test case illustrating
the problem.
Repeated calls to $x509->pubkey cause a noticiable memory leak.
FWIW, I looked over your code and did not spot anything amiss. Your
XSUB reduces down to 1) creating a new empty string SV in
sv_bio_create, 2) concatenting onto the end of that SV during the
callbacks (but never overwriting the pointer or doing anything else
that would cause the SV to get lost), then 3) retrieving that SV with
sv_bio_final and assigning it to RETVAL. It's just a plain string sv
with a refcount of 1.
The one thing that looks weird is this, in sv_bio_final():
if (!sv) {
sv = &PL_sv_undef;
}
That variable should never be null, because you've assigned it a
fresh SV in sv_bio_create(). If something within the guts of your C
code is turning it to null, you'll lose the SV and wind up with a leak.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
