Description of problem: These were revealed by running the libguestfs test suite under valgrind, using 'make check-valgrind'. ==19641== 0 bytes in 1 blocks are definitely lost in loss record 2 of 179 ==19641== at 0x4A06B2F: calloc (vg_replace_malloc.c:593) ==19641== by 0x4F729DB: virAllocN (viralloc.c:128) ==19641== by 0x5077CE2: virNetClientProgramCall (virnetclientprogram.c:300) ==19641== by 0x5055B45: callFull.isra.2 (remote_driver.c:5584) ==19641== by 0x5055DEE: call.isra.3 (remote_driver.c:5606) ==19641== by 0x50632AB: remoteDomainCreateXML (remote_client_bodies.h:412) ==19641== by 0x501A8F6: virDomainCreateXML (libvirt.c:1988) ==19641== by 0x4CAC30A: launch_libvirt (launch-libvirt.c:361) ==19641== by 0x401322: main (test-user-cancel.c:117) ==19641== ==19641== 0 bytes in 1 blocks are definitely lost in loss record 3 of 179 ==19641== at 0x4A06B2F: calloc (vg_replace_malloc.c:593) ==19641== by 0x4F729DB: virAllocN (viralloc.c:128) ==19641== by 0x5077CE2: virNetClientProgramCall (virnetclientprogram.c:300) ==19641== by 0x5055B45: callFull.isra.2 (remote_driver.c:5584) ==19641== by 0x5055DEE: call.isra.3 (remote_driver.c:5606) ==19641== by 0x5069E1D: doRemoteOpen (remote_driver.c:3463) ==19641== by 0x506B90C: remoteOpen (remote_driver.c:995) ==19641== by 0x5017C13: do_open (libvirt.c:1201) ==19641== by 0x5019A33: virConnectOpenAuth (libvirt.c:1441) ==19641== by 0x4CAD050: guestfs___open_libvirt_connection (libvirt-auth.c:195) ==19641== by 0x4CABCA6: launch_libvirt (launch-libvirt.c:187) ==19641== by 0x401322: main (test-user-cancel.c:117) ==19641== ==19641== 0 bytes in 1 blocks are definitely lost in loss record 4 of 179 ==19641== at 0x4A06B2F: calloc (vg_replace_malloc.c:593) ==19641== by 0x4F729DB: virAllocN (viralloc.c:128) ==19641== by 0x5077CE2: virNetClientProgramCall (virnetclientprogram.c:300) ==19641== by 0x5055B45: callFull.isra.2 (remote_driver.c:5584) ==19641== by 0x5055DEE: call.isra.3 (remote_driver.c:5606) ==19641== by 0x506A7C2: doRemoteOpen (remote_driver.c:823) ==19641== by 0x506B90C: remoteOpen (remote_driver.c:995) ==19641== by 0x5017C13: do_open (libvirt.c:1201) ==19641== by 0x5019A33: virConnectOpenAuth (libvirt.c:1441) ==19641== by 0x4CAD050: guestfs___open_libvirt_connection (libvirt-auth.c:195) ==19641== by 0x4CABCA6: launch_libvirt (launch-libvirt.c:187) ==19641== by 0x401322: main (test-user-cancel.c:117) ==19641== ==19641== 0 bytes in 1 blocks are definitely lost in loss record 5 of 179 ==19641== at 0x4A06B2F: calloc (vg_replace_malloc.c:593) ==19641== by 0x4F729DB: virAllocN (viralloc.c:128) ==19641== by 0x5077CE2: virNetClientProgramCall (virnetclientprogram.c:300) ==19641== by 0x5055B45: callFull.isra.2 (remote_driver.c:5584) ==19641== by 0x5055DEE: call.isra.3 (remote_driver.c:5606) ==19641== by 0x506B4DF: doRemoteOpen (remote_driver.c:835) ==19641== by 0x506B90C: remoteOpen (remote_driver.c:995) ==19641== by 0x5017C13: do_open (libvirt.c:1201) ==19641== by 0x5019A33: virConnectOpenAuth (libvirt.c:1441) ==19641== by 0x4CAD050: guestfs___open_libvirt_connection (libvirt-auth.c:195) ==19641== by 0x4CABCA6: launch_libvirt (launch-libvirt.c:187) ==19641== by 0x401322: main (test-user-cancel.c:117) ==19641== ==19641== 0 bytes in 1 blocks are definitely lost in loss record 6 of 179 ==19641== at 0x4A06B2F: calloc (vg_replace_malloc.c:593) ==19641== by 0x4F729DB: virAllocN (viralloc.c:128) ==19641== by 0x5077CE2: virNetClientProgramCall (virnetclientprogram.c:300) ==19641== by 0x5055B45: callFull.isra.2 (remote_driver.c:5584) ==19641== by 0x5055DEE: call.isra.3 (remote_driver.c:5606) ==19641== by 0x505DB23: remoteGetCapabilities (remote_client_bodies.h:3180) ==19641== by 0x5025DED: virConnectGetCapabilities (libvirt.c:6532) ==19641== by 0x4CABCDB: launch_libvirt (launch-libvirt.c:203) ==19641== by 0x401322: main (test-user-cancel.c:117) ==19641== ==19641== 0 bytes in 1 blocks are definitely lost in loss record 7 of 179 ==19641== at 0x4A06B2F: calloc (vg_replace_malloc.c:593) ==19641== by 0x4F729DB: virAllocN (viralloc.c:128) ==19641== by 0x5077CE2: virNetClientProgramCall (virnetclientprogram.c:300) ==19641== by 0x5055B45: callFull.isra.2 (remote_driver.c:5584) ==19641== by 0x5055DEE: call.isra.3 (remote_driver.c:5606) ==19641== by 0x5058CB6: remoteDomainDestroyFlags (remote_client_bodies.h:491) ==19641== by 0x501B4B7: virDomainDestroyFlags (libvirt.c:2290) ==19641== by 0x4CA9CC7: shutdown_libvirt (launch-libvirt.c:1409) ==19641== by 0x4C9CEF9: shutdown_backend (handle.c:378) ==19641== by 0x4C9D6E9: guestfs_close (handle.c:290) ==19641== by 0x4C9D794: close_handles (handle.c:392) ==19641== by 0x328C638DF0: __run_exit_handlers (exit.c:77) ==19641== ==19641== 0 bytes in 1 blocks are definitely lost in loss record 8 of 179 ==19641== at 0x4A06B2F: calloc (vg_replace_malloc.c:593) ==19641== by 0x4F729DB: virAllocN (viralloc.c:128) ==19641== by 0x5077CE2: virNetClientProgramCall (virnetclientprogram.c:300) ==19641== by 0x5055B45: callFull.isra.2 (remote_driver.c:5584) ==19641== by 0x5055DEE: call.isra.3 (remote_driver.c:5606) ==19641== by 0x506704B: doRemoteClose.isra.4 (remote_driver.c:1024) ==19641== by 0x5067154: remoteClose (remote_driver.c:1066) ==19641== by 0x5010A0E: virConnectDispose (datatypes.c:145) ==19641== by 0x4F9BFFA: virObjectUnref (virobject.c:264) ==19641== by 0x5019ABE: virConnectClose (libvirt.c:1492) ==19641== by 0x4CA9CE4: shutdown_libvirt (launch-libvirt.c:1417) ==19641== by 0x4C9CEF9: shutdown_backend (handle.c:378) Version-Release number of selected component (if applicable): libvirt-1.0.2-2.fc19.x86_64 How reproducible: 100% Steps to Reproduce: 1. In libguestfs, use 'make check-valgrind'.
Wierd. All these traces are saying "0 bytes" - so I'm not really sure what valgrind thinks is wrong here.
I guess calloc(0,0) is being called (and isn't returning NULL). That would still be a memory leak, since the malloc structure overhead is being leaked.
Hmm, I would have expected it to report '1 byte' leaked if calloc(0) returned non-NULL, but worth checking I guess.
I remember seeing a similar valgrind log on the list https://www.redhat.com/archives/libvir-list/2013-February/msg00813.html
Patch has been posted upstream. So I've pushed it: commit 1d8193ee8a7c9b6355468bd58e483d84fe1ed40b Author: Sergey Fionov <fionov> AuthorDate: Sun Feb 17 18:20:59 2013 +0400 Commit: Michal Privoznik <mprivozn> CommitDate: Wed Feb 20 17:56:35 2013 +0100 Fix memory leak in virNetClientIOWriteMessage Commit 18937c3ae0990b4417a43aa07a2c35aaf8cb6ec2 introduced the memory leak when client->msg.fds is copied to thecall->msg and then never freed. v1.0.2-208-g1d8193e Hence moving to POST.
Just closing as UPSTREAM, this is minor and will be fixed with the next libvirt update in rawhide