Description of problem:
Running 2 lvcreate mirror commands lead to internal memory leak,
in the function _parse_mirror_status, where device is tested for
usability. Allocated log and image strings are not released
after their use.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
For testing the only way how to detect this leak is to use valgrind and run 2 commands like 'lvcreate -m2 -L10M vg'
Current code results in leak like:
16544== 7 bytes in 1 blocks are indirectly lost in loss record 3 of 5
16544== at 0x4C2C87C: malloc (vg_replace_malloc.c:270)
16544== by 0x5BBAFC1: strdup (strdup.c:42)
16544== by 0x483498: dev_create_file (dev-cache.c:84)
16544== by 0x53106D: _ignore_blocked_mirror_devices (dev_manager.c:257)
16544== by 0x531B1E: device_is_usable (dev_manager.c:359)
16544== by 0x492024: _lookup_p (filter-persistent.c:297)
16544== by 0x48791B: dev_iter_get (dev-cache.c:1009)
16544== by 0x47324E: lvmcache_label_scan (lvmcache.c:692)
16544== by 0x4E120F: _vg_read (metadata.c:2981)
16544== by 0x4E3407: vg_read_internal (metadata.c:3397)
16544== by 0x4E5E3C: _vg_lock_and_read (metadata.c:4033)
16544== by 0x4E65D7: vg_read (metadata.c:4137)
16544== by 0x4E6633: vg_read_for_update (metadata.c:4148)
16544== by 0x42DE9D: lvcreate (lvcreate.c:1028)
16544== by 0x4364CE: lvm_run_command (lvmcmdline.c:1120)
16544== by 0x43867F: lvm2_main (lvmcmdline.c:1554)
16544== by 0x4679C1: main (lvm.c:21)
Fixed by upstream patch:
While the leak does not look huge, it is in the range of hundred bytes per command and per mirror, we have long-term running commands like dmeventd which should not leak memory, since the memory may accumulate over the time, and such memory is non-swappable and permanently locked in RAM - so leaving such leak may increase risk of getting OOM killer in action - so setting exception because of this risk.
Adding QA ACK as SanityOnly since no easy reproducer (in a normal amount of given time) is viable.
(it would probably accumulate in time as stated in Comment #4, but SanityOnly should suffice in this case I believe)
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.