Bug 214373

Summary:	Valgrind reports "possibly lost" for recent libcap
Product:	Tools	Reporter:	yan12125 (3cmqut5e44sxaake)
Component:	libcap	Assignee:	Andrew G. Morgan (morgan)
Status:	RESOLVED CODE_FIX
Severity:	normal	CC:	morgan
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	n/a	Subsystem:
Regression:	No	Bisected commit-id:

Description yan12125 2021-09-12 12:48:52 UTC

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

Comment 1 Andrew G. Morgan 2021-09-12 15:45:04 UTC

Thanks for this bug report. I'll take a look.

Comment 2 Andrew G. Morgan 2021-09-13 02:32:10 UTC

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)

Comment 3 yan12125 2021-09-13 02:57:29 UTC

Cool, thanks!