Created attachment 2846 [details]
Proposed patch

On my system libstdc++ "leaks" memory, something like what is described here:

https://stackoverflow.com/questions/30376601/valgrind-memory-still-reachable-with-trivial-program-using-iostream

I added the following suppression to testpy.supp:
{
   libstdcpp
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   obj:/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
}

I do not propose to add it as it should be fixed in valgrind itself.

However, adding suppression does not fix the problem, as valgrind still outputs
...
==3712811== LEAK SUMMARY:
==3712811==    definitely lost: 0 bytes in 0 blocks
==3712811==    indirectly lost: 0 bytes in 0 blocks
==3712811==      possibly lost: 0 bytes in 0 blocks
==3712811==    still reachable: 0 bytes in 0 blocks
==3712811==         suppressed: 72,704 bytes in 1 blocks
==3712811==
==3712811== For counts of detected and suppressed errors, rerun with: -v
==3712811== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)

"LEAK SUMMARY" is present, so just looking for "LEAK SUMMARY" is not enough, one must also look that there are bytes which are not suppressed.

I propose to stop parsing valgrind output and add option "--errors-for-leak-kinds=all" to make valgrind treat all leaks that are not suppressed as errors.