Ubuntu
multipath-tools package

  1. Bug #571093
  2. Comment #13

Comment 13 for bug 571093

Revision history for this message
Nigel Jones (dev-nigelj) wrote : Re: multipath + libvirtd eats away more memory over time

I've done a bit of an experiment and this is what I've found:

Running valgrind on libvirtd -v ($ sudo valgrind -v --leak-check=full --show-reachable=yes /usr/sbin/libvirtd -v) produced the output in lp571093-libvirt-val-run1

A quick summary:

==15520== 78,696 (18,048 direct, 60,648 indirect) bytes in 376 blocks are definitely lost in loss record 324 of 325
==15520== at 0x4C267CC: calloc (vg_replace_malloc.c:467)
==15520== by 0x42CFAD: virAlloc (memory.c:100)
==15520== by 0x47C96D: udevAddOneDevice (node_device_udev.c:1209)
==15520== by 0x47D166: udevDeviceMonitorStartup (node_device_udev.c:1265)
==15520== by 0x54BD1BF: virStateInitialize (in /usr/lib/libvirt.so.0.7.5)
==15520== by 0x41A64B: main (libvirtd.c:3153)
==15520==
==15520== 204,320 (22,736 direct, 181,584 indirect) bytes in 98 blocks are definitely lost in loss record 325 of 325
==15520== at 0x4C267CC: calloc (vg_replace_malloc.c:467)
==15520== by 0x50508CB: udev_device_new (libudev-device.c:240)
==15520== by 0x505285C: udev_monitor_receive_device (libudev-monitor.c:589)
==15520== by 0x47D367: udevEventHandleCallback (node_device_udev.c:1356)
==15520== by 0x414AF8: virEventRunOnce (event.c:478)
==15520== by 0x4166D8: qemudOneLoop (libvirtd.c:2169)
==15520== by 0x4169B2: qemudRunLoop (libvirtd.c:2278)
==15520== by 0x70669C9: start_thread (pthread_create.c:300)
==15520== by 0x736369C: clone (clone.S:112)

==15520== LEAK SUMMARY:
==15520== definitely lost: 46,856 bytes in 628 blocks
==15520== indirectly lost: 282,769 bytes in 8,181 blocks
==15520== possibly lost: 0 bytes in 0 blocks
==15520== still reachable: 109,152 bytes in 1,303 blocks
==15520== suppressed: 0 bytes in 0 blocks
==15520==

I triggered the issue by running:
$ sudo multipath -F
$ sudo multipath -v4
multiple times to replicate the issue.

I'd say that this is definitely a libvirt/udev bug based on the behaviour. I believe that while Nick's suggestion in Comment #9 may avoid the problem it looks like it's really a bandaid and it's possible that other applications will trigger this issue via udev.