You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
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. [...]"
A simple init & close cause 2 not-freed blocks (libusb #231)
The text was updated successfully, but these errors were encountered: