Description of problem: When using plain 'lvcreate' valgrind now shows 2 left block when command is finished - lvm2 calls documented unref() calls, so assumption is something is left something by udev. 4,096 bytes in 1 blocks are still reachable in loss record 1 of 2 at 0x4C2DC50: malloc (vg_replace_malloc.c:299) by 0x406C88F: mempool_alloc_tile (mempool.c:61) by 0x406C88F: mempool_alloc0_tile (mempool.c:80) by 0x406C88F: hashmap_base_new (hashmap.c:790) by 0x406C88F: hashmap_base_ensure_allocated.lto_priv.37 (hashmap.c:844) by 0x406B110: UnknownInlinedFun (hashmap.c:861) by 0x406B110: sd_device_enumerator_add_match_subsystem (device-enumerator.c:120) by 0x18E506: _insert_udev_dir (dev-cache.c:524) by 0x18E75F: _insert_dirs (dev-cache.c:583) by 0x18EB05: _full_scan (dev-cache.c:663) by 0x18FD3B: dev_iter_create (dev-cache.c:1058) by 0x17AEE1: lvmcache_label_scan (lvmcache.c:759) by 0x1DED99: _vg_read (metadata.c:3608) by 0x1DFFDF: vg_read_internal (metadata.c:4016) by 0x1E2463: _vg_lock_and_read (metadata.c:5012) by 0x1E27FD: vg_read (metadata.c:5112) by 0x1E2842: vg_read_for_update (metadata.c:5123) by 0x147865: lvcreate (lvcreate.c:1473) by 0x14EDA0: lvm_run_command (lvmcmdline.c:1655) by 0x150117: lvm2_main (lvmcmdline.c:2121) by 0x172D5D: main (lvm.c:22) 4,096 bytes in 1 blocks are still reachable in loss record 2 of 2 at 0x4C2DC50: malloc (vg_replace_malloc.c:299) by 0x406C88F: mempool_alloc_tile (mempool.c:61) by 0x406C88F: mempool_alloc0_tile (mempool.c:80) by 0x406C88F: hashmap_base_new (hashmap.c:790) by 0x406C88F: hashmap_base_ensure_allocated.lto_priv.37 (hashmap.c:844) by 0x406376B: UnknownInlinedFun (hashmap.c:857) by 0x406376B: device_add_property_aux.constprop.12 (sd-device.c:106) by 0x406C995: UnknownInlinedFun (sd-device.c:142) by 0x406C995: device_set_syspath (sd-device.c:206) by 0x406CFAE: sd_device_new_from_syspath (sd-device.c:230) by 0x4067AFC: enumerator_scan_dir_and_add_devices.lto_priv.59 (device-enumerator.c:500) by 0x4067EB7: enumerator_scan_dir.lto_priv.60 (device-enumerator.c:608) by 0x405FEB4: enumerator_scan_devices_all (device-enumerator.c:826) by 0x405FEB4: device_enumerator_scan_devices (device-enumerator.c:858) by 0x405FEB4: udev_enumerate_scan_devices (libudev-enumerate.c:403) by 0x18E51A: _insert_udev_dir (dev-cache.c:525) by 0x18E75F: _insert_dirs (dev-cache.c:583) by 0x18EB05: _full_scan (dev-cache.c:663) by 0x18FD3B: dev_iter_create (dev-cache.c:1058) by 0x17AEE1: lvmcache_label_scan (lvmcache.c:759) by 0x1DED99: _vg_read (metadata.c:3608) by 0x1DFFDF: vg_read_internal (metadata.c:4016) Version-Release number of selected component (if applicable): systemd-227-3.fc24.x86_64 How reproducible: Steps to Reproduce: 1. valgrind lvcreate -L10 vg 2. 3. Actual results: Expected results: Additional info:
Yeah, 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. Closing.