As https://github.com/aws/s2n-tls/pull/3506 demonstrated we were not doing proper cleanup. This was not caught by Vangrind because by default Valgrind ignores "Still reachable" leaks (For more info see https://valgrind.org/docs/manual/mc-manual.html). This might be a safe assumption for applications but not for our library. We should therefore enable --errors-for-leak-kinds=all check; aka run Valgrind in pedantic mode.
We currently run Valgrind for multiple compilers and libcryptos. Unfortunately, each does allocate/cleanup in a different manner and can require special code. However, I argue that pedantic mode can be enabled incrementally and that we get 80% of the benefit from enabling pedantic for a single combination (we would have caught the leak in https://github.com/aws/s2n-tls/pull/3506).
Therefore the goal of the MVP is to
enable pedantic mode in CI
enable Valgrind pedantic mode for OSSL 1.1.1 and GCC_9
add suppression if needed to unblock the task
Post MVP we should incrementally enable pedantic mode for all combinations and all tests (remove suppression).
Problem:
As https://github.com/aws/s2n-tls/pull/3506 demonstrated we were not doing proper cleanup. This was not caught by Vangrind because by default Valgrind ignores "Still reachable" leaks (For more info see https://valgrind.org/docs/manual/mc-manual.html). This might be a safe assumption for applications but not for our library. We should therefore enable
--errors-for-leak-kinds=all
check; aka run Valgrind in pedantic mode.We currently run Valgrind for multiple compilers and libcryptos. Unfortunately, each does allocate/cleanup in a different manner and can require special code. However, I argue that pedantic mode can be enabled incrementally and that we get 80% of the benefit from enabling pedantic for a single combination (we would have caught the leak in https://github.com/aws/s2n-tls/pull/3506).
Therefore the goal of the MVP is to
Post MVP we should incrementally enable pedantic mode for all combinations and all tests (remove suppression).
MVP
Post MVP:
Memory leaks on remaining Libcrypto tests
Memory failures for
awslc-fips
is involved and needs to be debugged. For OpenSSL-1.0.2, the leaks seem to be coming from a single test.openssl-1.0.2
and
openssl-1.0.2-fips: below are the memory leaks for the openssl-1.0.2 librcrypto.`openssl-1.0.2` and `openssl-1.0.2-fips failures`