libusb: init & close cause 2 not-freed blocks

[Ventto]

A simple init & close cause 2 not-freed blocks (libusb #231)

==3893== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 2
==3893==    at 0x4C29BBE: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3893==    by 0x405B0EF: ??? (in /usr/lib/libudev.so.1.6.5)
==3893==    by 0x405F300: ??? (in /usr/lib/libudev.so.1.6.5)
==3893==    by 0x4E4518C: ??? (in /usr/lib/libusb-1.0.so.0.1.0)
==3893==    by 0x4E42D50: ??? (in /usr/lib/libusb-1.0.so.0.1.0)
==3893==    by 0x4E3B18C: libusb_init (in /usr/lib/libusb-1.0.so.0.1.0)
==3893==    by 0x40136A: main (main.c:60)
==3893== 
==3893== 4,096 bytes in 1 blocks are still reachable in loss record 2 of 2
==3893==    at 0x4C29BBE: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3893==    by 0x405B0EF: ??? (in /usr/lib/libudev.so.1.6.5)
==3893==    by 0x405AA2B: ??? (in /usr/lib/libudev.so.1.6.5)
==3893==    by 0x406333B: ??? (in /usr/lib/libudev.so.1.6.5)
==3893==    by 0x40614A2: ??? (in /usr/lib/libudev.so.1.6.5)
==3893==    by 0x405EE9F: ??? (in /usr/lib/libudev.so.1.6.5)
==3893==    by 0x4064206: ??? (in /usr/lib/libudev.so.1.6.5)
==3893==    by 0x405C08B: udev_enumerate_scan_devices (in /usr/lib/libudev.so.1.6.5)
==3893==    by 0x4E45194: ??? (in /usr/lib/libusb-1.0.so.0.1.0)
==3893==    by 0x4E42D50: ??? (in /usr/lib/libusb-1.0.so.0.1.0)
==3893==    by 0x4E3B18C: libusb_init (in /usr/lib/libusb-1.0.so.0.1.0)
==3893==    by 0x40136A: main (main.c:60)

[bphiett]

I have exactly the same valgrind output - did you find a solution?

[Ventto]

It seems to come from an udev's cache issue.

• From @ao2 (libusb #231), "As reported in fedora this is not an actual leak, but an effect of some allocation cache used by udev [...]"

• From Bugzilla comments: "[...] systemd maintains an allocation cache. The data is not leaked, it's reused on subsequent allocations. valgrind will show them only if you explicitly ask it to also show referenced memory still. Maintaining allocation caches is pretty common, and not a leak or bug. [...]"