Bug 1280334 - udev API leaks 8k
Summary: udev API leaks 8k
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-11 13:54 UTC by Zdenek Kabelac
Modified: 2016-02-10 13:58 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-10 13:58:17 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Zdenek Kabelac 2015-11-11 13:54:40 UTC
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:

Comment 1 Lennart Poettering 2016-02-10 13:58:17 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.