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:

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
[download]

(see PERL_DESTRUCT_LEVEL)

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.