Red Hat Bugzilla – Bug 798497
Plug memory leak on migration
Last modified: 2012-06-20 02:49:18 EDT
Description of problem:
Plug memory leak on migration.
Version-Release number of selected component (if applicable):
# rpm -q libvirt
Steps to Reproduce:
1. configure migration environment
2. virsh start <domain>
3. valgrind -v --leak-check=full virsh migrate <domain> qemu+ssh://<target ip>/system --unsafe
==30879== 8 bytes in 1 blocks are definitely lost in loss record 1 of 30
==30879== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==30879== by 0x39CF115FB8: xdr_reference (in /lib64/libc-2.12.so)
==30879== by 0x39CF115F10: xdr_pointer (in /lib64/libc-2.12.so)
==30879== by 0x4D52614: xdr_remote_string (remote_protocol.c:40)
==30879== by 0x4D52680: xdr_remote_domain_migrate_prepare3_ret (remote_protocol.c:4772)
==30879== by 0x4D6F742: virNetMessageDecodePayload (virnetmessage.c:382)
==30879== by 0x4D5BCDF: virNetClientProgramCall (virnetclientprogram.c:382)
==30879== by 0x4D384EB: callWithFD (remote_driver.c:4547)
==30879== by 0x4D3858B: call (remote_driver.c:4568)
==30879== by 0x4D44F34: remoteDomainMigratePrepare3 (remote_driver.c:4136)
==30879== by 0x4D27240: virDomainMigrateVersion3 (libvirt.c:4809)
==30879== by 0x4D28A6C: virDomainMigrate2 (libvirt.c:5448)
==30879== LEAK SUMMARY:
==30879== definitely lost: 8 bytes in 1 blocks
avoid memory leak.
Alex, do you have a patch for this one?
(In reply to comment #1)
> Alex, do you have a patch for this one?
I'm trying to find a right place to fix the leak firstly.
patch posted internally, move to POST.
Osier, can you describe the leak? Is the leak in virsh or the daemon or both, and what action by the user causes the leak to occur? Is it an error path or a normal use case?
(In reply to comment #6)
> Osier, can you describe the leak? Is the leak in virsh or the daemon or both,
> and what action by the user causes the leak to occur? Is it an error path or a
> normal use case?
It's leak in remote driver, so each libvirt client will leak, no leak in daemon.
It's not a error path, just a normal use case will cause that.
Ok, given that, we need to fix this in 6.3.
(In reply to comment #8)
> Ok, given that, we need to fix this in 6.3.
Yes, it's leak after every migration operation.
Verify pass on
Start a guest without cache=none for its disk
No memory leak after migration with --unsafe
==17411== LEAK SUMMARY:
==17411== definitely lost: 0 bytes in 0 blocks
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
No documentation needed.
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.