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): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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: https://www.redhat.com/archives/lvm-devel/2012-December/msg00018.html
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. http://rhn.redhat.com/errata/RHBA-2013-0501.html