Linux: init & close cause 2 not-freed blocks

[Ventto]

I don't understand why a simple init & close causes at least 2 not-freed blocks. Any lead ?
I am pretty sure this issue was mentioned but unfortunately haven't found yet.

The result is the same with the examples on the repo.

Nothing to report with LIBUSB_LOG_LEVEL_DEBUG set.

Plateform: Archlinux x86_64
Libusb: v1.0.21-1

• Valgrind logs:

==6196== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 2
==6196==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6196==    by 0x405D0EF: ??? (in /usr/lib/libudev.so.1.6.5)
==6196==    by 0x4061300: ??? (in /usr/lib/libudev.so.1.6.5)
==6196==    by 0x4E4718C: ??? (in /usr/lib/libusb-1.0.so.0.1.0)
==6196==    by 0x4E44D50: ??? (in /usr/lib/libusb-1.0.so.0.1.0)
==6196==    by 0x4E3D18C: libusb_init (in /usr/lib/libusb-1.0.so.0.1.0)
==6196==    by 0x4008F3: main (in /home/tom/workspace/c/qemip/test)
==6196== 
==6196== 4,096 bytes in 1 blocks are still reachable in loss record 2 of 2
==6196==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6196==    by 0x405D0EF: ??? (in /usr/lib/libudev.so.1.6.5)
==6196==    by 0x405CA2B: ??? (in /usr/lib/libudev.so.1.6.5)
==6196==    by 0x406533B: ??? (in /usr/lib/libudev.so.1.6.5)
==6196==    by 0x40634A2: ??? (in /usr/lib/libudev.so.1.6.5)
==6196==    by 0x4060E9F: ??? (in /usr/lib/libudev.so.1.6.5)
==6196==    by 0x4066206: ??? (in /usr/lib/libudev.so.1.6.5)
==6196==    by 0x405E08B: udev_enumerate_scan_devices (in /usr/lib/libudev.so.1.6.5)
==6196==    by 0x4E47194: ??? (in /usr/lib/libusb-1.0.so.0.1.0)
==6196==    by 0x4E44D50: ??? (in /usr/lib/libusb-1.0.so.0.1.0)
==6196==    by 0x4E3D18C: libusb_init (in /usr/lib/libusb-1.0.so.0.1.0)
==6196==    by 0x4008F3: main (in /home/tom/workspace/c/qemip/test)

Thank you.

[LudovicRousseau]

My first guess would be to look at the hotplug thread.

[dickens]

I definitely believe this is a libudev issue. You can file an issue against that library if you'd like, referencing this issue for details.

==21263== HEAP SUMMARY:
==21263==     in use at exit: 8,192 bytes in 2 blocks
==21263==   total heap usage: 1,703 allocs, 1,701 frees, 745,053 bytes allocated
==21263== 
==21263== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 2
==21263==    at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21263==    by 0x404760F: mempool_alloc_tile (mempool.c:61)
==21263==    by 0x404760F: mempool_alloc0_tile (mempool.c:80)
==21263==    by 0x404760F: hashmap_base_new (hashmap.c:789)
==21263==    by 0x404760F: hashmap_base_ensure_allocated.lto_priv.36 (hashmap.c:843)
==21263==    by 0x4049860: UnknownInlinedFun (hashmap.c:860)
==21263==    by 0x4049860: sd_device_enumerator_add_match_subsystem (device-enumerator.c:120)
==21263==    by 0x4E4486C: linux_udev_scan_devices (linux_udev.c:272)
==21263==    by 0x4E431B5: linux_scan_devices (linux_usbfs.c:502)
==21263==    by 0x4E431B5: op_init (linux_usbfs.c:454)
==21263==    by 0x4E3AF8C: libusb_init (core.c:2125)
==21263==    by 0x4009BE: main (listdevs.c:58)
==21263== 
==21263== 4,096 bytes in 1 blocks are still reachable in loss record 2 of 2
==21263==    at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21263==    by 0x404760F: mempool_alloc_tile (mempool.c:61)
==21263==    by 0x404760F: mempool_alloc0_tile (mempool.c:80)
==21263==    by 0x404760F: hashmap_base_new (hashmap.c:789)
==21263==    by 0x404760F: hashmap_base_ensure_allocated.lto_priv.36 (hashmap.c:843)
==21263==    by 0x4044E3B: UnknownInlinedFun (hashmap.c:856)
==21263==    by 0x4044E3B: device_add_property_aux.constprop.12 (sd-device.c:106)
==21263==    by 0x4049C23: UnknownInlinedFun (sd-device.c:142)
==21263==    by 0x4049C23: device_set_syspath (sd-device.c:207)
==21263==    by 0x404A1FE: sd_device_new_from_syspath (sd-device.c:231)
==21263==    by 0x40448BF: enumerator_scan_dir_and_add_devices.lto_priv.56 (device-enumerator.c:500)
==21263==    by 0x4044C87: enumerator_scan_dir.lto_priv.57 (device-enumerator.c:608)
==21263==    by 0x403EF8B: enumerator_scan_devices_all (device-enumerator.c:822)
==21263==    by 0x403EF8B: device_enumerator_scan_devices (device-enumerator.c:860)
==21263==    by 0x403EF8B: udev_enumerate_scan_devices (libudev-enumerate.c:403)
==21263==    by 0x4E4488A: linux_udev_scan_devices (linux_udev.c:274)
==21263==    by 0x4E431B5: linux_scan_devices (linux_usbfs.c:502)
==21263==    by 0x4E431B5: op_init (linux_usbfs.c:454)
==21263==    by 0x4E3AF8C: libusb_init (core.c:2125)
==21263==    by 0x4009BE: main (listdevs.c:58)
==21263== 
==21263== LEAK SUMMARY:
==21263==    definitely lost: 0 bytes in 0 blocks
==21263==    indirectly lost: 0 bytes in 0 blocks
==21263==      possibly lost: 0 bytes in 0 blocks
==21263==    still reachable: 8,192 bytes in 2 blocks
==21263==         suppressed: 0 bytes in 0 blocks

[bphiett]

I have observed the exact same issue in my valgrind output - sounds like there isn't a solution?

[ao2]

As reported in fedora this is not an actual leak, but an effect of some allocation cache used by udev: https://bugzilla.redhat.com/show_bug.cgi?id=1280334

The following suppression file can be used to silence the issue when profiling libusb programs:

{
   Suppress a false positive about the udev allocation cache, see https://github.com/libusb/libusb/issues/231
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   obj:/lib/x86_64-linux-gnu/libudev.so.1.6.*
   obj:/lib/x86_64-linux-gnu/libudev.so.1.6.*
   obj:/lib/x86_64-linux-gnu/libusb-1.0.so.0.1.*
   obj:/lib/x86_64-linux-gnu/libusb-1.0.so.0.1.*
   fun:libusb_init
}

{
   Suppress a false positive about the udev allocation cache, see https://github.com/libusb/libusb/issues/231
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   obj:/lib/x86_64-linux-gnu/libudev.so.1.6.*
   obj:/lib/x86_64-linux-gnu/libudev.so.1.6.*
   obj:/lib/x86_64-linux-gnu/libudev.so.1.6.*
   obj:/lib/x86_64-linux-gnu/libudev.so.1.6.*
   obj:/lib/x86_64-linux-gnu/libudev.so.1.6.*
   obj:/lib/x86_64-linux-gnu/libudev.so.1.6.*
   fun:udev_enumerate_scan_devices
   obj:/lib/x86_64-linux-gnu/libusb-1.0.so.0.1.*
   obj:/lib/x86_64-linux-gnu/libusb-1.0.so.0.1.*
   fun:libusb_init
}

Maybe something like this into a libusb-udev.supp file can be added to the libusb repository as a reminder.

Ciao,
Antonio