Steps to reproduce: 1. `make DYNAMIC=yes COPTS="-g"` 2. `LD_LIBRARY_PATH="$PWD/libcap" valgrind --leak-check=full ./progs/capsh` ``` ==13429== Memcheck, a memory error detector ==13429== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==13429== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info ==13429== Command: ./progs/capsh ==13429== ==13429== ==13429== HEAP SUMMARY: ==13429== in use at exit: 96 bytes in 1 blocks ==13429== total heap usage: 2 allocs, 1 frees, 192 bytes allocated ==13429== ==13429== 96 bytes in 1 blocks are possibly lost in loss record 1 of 1 ==13429== at 0x48435FF: calloc (vg_replace_malloc.c:1117) ==13429== by 0x485371D: _libcap_strdup (cap_alloc.c:110) ==13429== by 0x48579AE: cap_proc_root (cap_text.c:690) ==13429== by 0x48535DD: ??? (cap_alloc.c:22) ==13429== by 0x400FE2D: call_init (in /usr/lib/ld-2.33.so) ==13429== by 0x400FF1B: _dl_init (in /usr/lib/ld-2.33.so) ==13429== by 0x40010C9: ??? (in /usr/lib/ld-2.33.so) ==13429== ==13429== LEAK SUMMARY: ==13429== definitely lost: 0 bytes in 0 blocks ==13429== indirectly lost: 0 bytes in 0 blocks ==13429== possibly lost: 96 bytes in 1 blocks ==13429== still reachable: 0 bytes in 0 blocks ==13429== suppressed: 0 bytes in 0 blocks ==13429== ==13429== For lists of detected and suppressed errors, rerun with: -s ==13429== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ``` The reported leak seems from https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=b56400f81ddd42e0e57372c957e668e6d5a72834 I noticed this when running a Qt program under valgrind. On Arch Linux, the link path is libQt5Core.so -> libsystemd.so -> libcap.so. As the issue is from a constructor, such leaks are reported for all Qt programs. I wonder if putting something like `cap_free(cap_proc_root(NULL))` in a destructor is a good idea or not. A user can also do that, and doing it again in a destructor causes double free. Tested environment: OS: Arch Linux gcc: 11.1.0 valgrind: 3.17.0 libcap: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=280110a9caf8510af9775bb75942d050134c12d9
Thanks for this bug report. I'll take a look.
Thanks for the reproducer. This fixes it, essentially in the way you suggested: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=a3446b5c6e0879b289287c9a87a57cbdc95e99da $ LD_LIBRARY_PATH="$PWD/libcap" valgrind --leak-check=full ./progs/capsh ==280072== Memcheck, a memory error detector ==280072== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==280072== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info ==280072== Command: ./progs/capsh ==280072== ==280072== ==280072== HEAP SUMMARY: ==280072== in use at exit: 0 bytes in 0 blocks ==280072== total heap usage: 2 allocs, 2 frees, 192 bytes allocated ==280072== ==280072== All heap blocks were freed -- no leaks are possible ==280072== ==280072== For lists of detected and suppressed errors, rerun with: -s ==280072== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Cool, thanks!