I'm performing a Asan run on GnuPG 2.2.15 and all of its dependencies. Everything was built with -fsanitize=address -fno-omit-frame-pointer. For Autotools projects the two flags get placed in CFLAGS, CXXFLAGS and LDFLAGS.
It looks like Asan is producing a finding for libgcrypt.
================================================================= ==13505==ERROR: LeakSanitizer: detected memory leaks Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7fc86c8b3c08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08) #1 0x7fc86c5a63cb in do_malloc /build/libgcrypt-1.8.4/src/global.c:918 #2 0x40410f in _GLOBAL__sub_I_00099_1_mpitests.c (/build/libgcrypt-1.8.4/tests/mpitests+0x40410f) Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x7fc86c8b3c08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08) #1 0x7fc86c5a63cb in do_malloc /build/libgcrypt-1.8.4/src/global.c:918 #2 0x7fff1c156287 ([stack]+0x1e287) SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s). FAIL: mpitests
This finding kind of sucks. It probably does not matter much for a desktop running GnuPG because the memory gets cleaned up when GnuPG exits.
But it really sucks for programs in managed languages like C# and Java. C# and Java will load and unload the libgcrypt shared object multiple times during the life of the program. The memory leaks will grow unbounded until all memory is exhausted. This issue causes the OpenJDK folks a lot of problems. (Just ask them about the OpenSSL memory leaks).
I did not look at the code in detail. For triage... For compilers and runtime environments that support it, use __attribute__((destructor)) to clear the leak.