This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1280334 - udev API leaks 8k
udev API leaks 8k
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-11 08:54 EST by Zdenek Kabelac
Modified: 2016-02-10 08:58 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-10 08:58:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Zdenek Kabelac 2015-11-11 08:54:40 EST
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 08:58:17 EST
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.