On Jan 8, 2007, at 1:14 PM, Dan Sully wrote:
==30258== 436 (112 direct, 324 indirect) bytes in 1 blocks are
definitely lost in loss record 11 of 16
==30258== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==30258== by 0x56CC911: CRYPTO_malloc (in /usr/lib/libcrypto.so.
0.9.8)
==30258==
==30258==
==30258== 788 bytes in 53 blocks are definitely lost in loss record
13 of 16
==30258== at 0x4A2080E: malloc (vg_replace_malloc.c:149)
==30258== by 0x499A85: Perl_safesysmalloc (util.c:78)
==30258== by 0x49B7DF: Perl_savepvn (util.c:789)
==30258== by 0x42D8C7: Perl_gv_fetchpv (gv.c:754)
==30258== by 0x427C2C: S_init_main_stash (perl.c:3510)
==30258== by 0x42210A: S_parse_body (perl.c:1657)
==30258== by 0x421DE1: perl_parse (perl.c:1598)
==30258== by 0x41D674: main (perlmain.c:97)
If I comment out some of the openssl calls, the CRYPTO_malloc leak
goes away,
but the perl one is still there. How would I find out what part of
my XS code
is causing that leak?
I believe that perl_parse leak is harmless. It seems to me that the
only way a parsing leak would cause major problems is if there were
continuous, ongoing leaks under eval $string. Such a problem
probably would not derive from your XS code in particular.
Since you can't get rid of that leak when running under -Mblib, it
probably makes sense to suppress it. Setting up a Valgrind
suppressions file is cake. Just ask it to generate suppressions for
you, then edit down the output and stick it in a file.
$ valgrind --leak-check=full --show-reachable=yes \
--gen-suppressions=yes /usr/local/debugperl/bin/perl5.8.8 \
-Mblib t/test_with_no_problems.t
Here's a suppressions file cooked up for Perl 5.8.8 running under
RedHat 9...
http://www.rectangular.com/svn/kinosearch/trunk/devel/
p588_valgrind.supp
... and here's a script which runs an entire test suite under
valgrind, logging the output:
http://www.rectangular.com/svn/kinosearch/trunk/devel/
valgrind_test.plx
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
