- New upstream release 1.17
- The Test::Valgrind tests will now be skipped when the default and
user-supplied suppressions files do not refer to any perl-related symbol;
this behaviour can be overridden by passing 'allow_no_supp => 1' to
Test::Valgrind->import
- Fix CPAN RT#101934: t/20-bad.t failing on armv7hl; while the root cause of
this issue is probably not at Test::Valgrind's level, it should
nevertheless not run the tests when the suppression files are obviously
insufficient
- The accuracy of the default perl suppression file has been improved
- The tests will be more reliably skipped when no valgrind or no suppressions
are found
- Segmentation faults during the analysis are now more gracefully handled
- 'no_def_supp => 1' will no longer cause the extra suppressions to be
ignored
- t/20-bad.t will no longer run the extra tests when no valgrind can be found
(this was a regression in version 1.15)
- Bump version requirements for File::Temp/Test::Builder usage in test suite
- Drop redundant %{?perl_default_filter}
- New upstream release 1.15
- The new 'regen_def_supp' option can be passed to Test::Valgrind->import to
forcefully regenerate the default suppression file
- Fix build failures of the dummy XS code with PERL_IMPLICIT_SYS perls
- Fix handshake failures in tests with recent perls built with PERL_POISON
- Test: Improved diagnostics on failure
- Freshen Makefile.PL
- New upstream release 1.14
- This is a maintenance release; the code contains no functional change
- POD headings are now properly linkable
- Author tests are no longer bundled with this distribution
- The stack traces used in t/20-bad.t have been made more predictable when
compiler optimizations are in use
- Drop buildreqs only needed for author tests
The Test::Valgrind::* API lets you run Perl code through the memcheck tool of
the valgrind memory debugger, to test for memory errors and leaks. The
Test::Valgrind module itself is a front-end to this API. If they aren't
available yet, it will first generate suppressions for the current perl
interpreter and store them in the portable flavor of
~/.perl/Test-Valgrind/suppressions/$VERSION. The actual run will then take
place, and tests will be passed or failed according to the result of the
analysis.
The complete API is much more versatile than this. By declaring an appropriate
Test::Valgrind::Command class, you can run any executable (that is, not only
Perl scripts) under valgrind, generate the corresponding suppressions
on-the-fly and convert the analysis result to TAP output so that it can be
incorporated into your project's test suite. If you're not interested in
producing TAP, you can output the results in whatever format you like (for
example HTML pages) by defining your own Test::Valgrind::Action class.
Paul Howarth
Fedora Release Engineering