I have no idea if your code is leaky but Perl runs its own memory pool and garbage collection and this causes valgrind to show lots of memory not free'ed at the end (as NERDVANA also said). There is a way to tell perl to free all memory at the end:
(see PERL_DESTRUCT_LEVEL)PERL_DESTRUCT_LEVEL If you want to run any of the tests yourself manually using e.g. valgr +ind, please note that by default perl does not explicitly clean up al +l the memory it has allocated (such as global memory arenas) but inst +ead lets the exit() of the whole program "take care" of such allocati +ons, also known as "global destruction of objects". There is a way to tell perl to do complete cleanup: set the environmen +t variable PERL_DESTRUCT_LEVEL to a non-zero value. The t/TEST wrappe +r does set this to 2, and this is what you need to do too, if you don +'t want to see the "global leaks": For example, for running under val +grind env PERL_DESTRUCT_LEVEL=2 valgrind ./perl -Ilib t/foo/bar.t
There are lots of situations where valgrind complains in this way, e.g. with Qt or Xlib. "Valgrind suppression files" are used to tell valgrind what not to report for each of these situations. I am not sure if there is one for perl but perhaps Test::Valgrind can do this and without messing with those pesky command line switches.
Finally, I would create the simplest XS code which does nothing at all and pass that through valgrind in order to confirm that what I said indeed applies and how to suppress/filter-in the good stuff.
In reply to Re: Memory Leak with XS but not pure C
by bliako
in thread Memory Leak with XS but not pure C
by FrankFooty
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |