script/valgrind.supp


Log

Author Commit Date CI Message
Edward Thomson c9b80c25 2021-08-21T15:28:45 valgrind: suppress leaks in dlopen and newer libraries dlopen sets up some thread-local state that isn't cleaned up by `dlclose`. Additionally, now that we're linking against different versions of libssh2 and OpenSSL, we're seeing different leak signatures.
Edward Thomson 2ad3eb3e 2019-11-24T15:59:26 valgrind: add suppressions for undefined use valgrind will warn that OpenSSL will use undefined data in connect/read when talking to certain other TLS stacks. Thankfully, this only seems to occur when gcc is the compiler, so hopefully valgrind is just misunderstanding an optimization. Regardless, suppress this warning.
Edward Thomson 6df3ec4a 2019-11-23T21:14:32 valgrind: suppress libssh2_rsa_sha1_sign leaks
Edward Thomson 7adc32d5 2019-11-23T13:02:29 valgrind: suppress kexinit leaks
Edward Thomson 5dc1be8d 2019-11-23T11:25:56 valgrind: suppress uninitialized reads in libcrypto libcrypto will read uninitialized memory as entropy. Suppress warnings from this behavior.
Patrick Steinhardt 56d5b443 2019-09-21T17:55:54 valgrind: suppress memory leaks in libssh2_session_handshake On Ubuntu, the combination of libgcrypt and libssh2 is quite old and known to contain memory leaks. We thus have several functions listed in our suppressions file that are known to leak. Due to a recent update of libssh2 or libgcrypt, there now are new memory leaks caused by libssh2_session_handshake and libssh2_init that cause the CI to fail. Add a new suppression to fix the issue.
Patrick Steinhardt d827b11b 2019-06-28T13:20:54 tests: execute leak checker via CTest directly Right now, we have an awful hack in our test CI setup that extracts the test command from CTest's output and then prepends the leak checker. This is dependent on non-machine-parseable output from CMake and also breaks on various ocassions, like for example when we have spaces in the current path or when the path contains backslashes. Both conditions may easily be triggered on Win32 systems, and in fact they do break our Azure Pipelines builds. Remove the awful hack in favour of a new CMake build option "USE_LEAK_CHECKER". If specifying e.g. "-DUSE_LEAK_CHECKER=valgrind", then we will set up all tests to be run under valgrind. Like this, we can again simply execute ctest without needing to rely on evil sourcery.