Potential memory leak warnings on Arch Linux

[glitsj16]

When building bpftune from git on Arch Linux I'm seeing a few warnings:

[...]
clang --analyze -I../include -I/usr/include -I/usr/include/libnl3 -I../include/uapi libbpftune.c bpftune.c tcp_buffer_tuner.c route_table_tuner.c neigh_table_tuner.c sysctl_tuner.c tcp_cong_tuner.c netns_tuner.c net_buffer_tuner.c
warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats
warning: Path diagnostic report is not generated. Current output format does not support diagnostics that cross file boundaries. Refer to --analyzer-output for valid output formats
In file included from libbpftune.c:55:
./probe.skel.h:203:2: warning: Potential leak of memory pointed to by 's' [unix.Malloc]
        return err;
        ^~~~~~~~~~
In file included from libbpftune.c:56:
./probe.skel.legacy.h:203:2: warning: Potential leak of memory pointed to by 's' [unix.Malloc]
        return err;
        ^~~~~~~~~~
2 warnings generated.
[...]

bpftune seems to be working fine though, so I'm not sure this is something worth looking into.

Additional info:

$ pacman -Q bpf clang libbpf libcap libnl llvm python-docutils
bpf 6.3-2
clang 15.0.7-9
libbpf 1.2.0-1
libcap 2.69-1
libnl 3.7.0-3
llvm 15.0.7-3
llvm-libs 15.0.7-3
python-docutils 1:0.20.1-1

[alan-maguire]

thanks for the info on arch linux builds! I see these warnings too; they originate from the bpf skeleton code generated via bpftool, so aren't really specific to bpftune. the warning seems to suggest that the skeleton object memory isn't freed, but bpf_object__destroy_skeleton() appears to free the calloc'ed memory to me. Perhaps it's just that the analysis doesn't include what libbpf does in bpf_object__destroy_skeleton().

[glitsj16]

thanks for the info on arch linux builds!

Very welcome. The bpftune application is a gem, glad I found it in the AUR.

Regarding those warnings. Thank you for looking into it and explaining. Looks more cosmetic than functional indeed. I'll keep an eye out nonetheless, but for now this issue can be closed.

Thanks again for your time.