Bug 913145

Summary:	Misc leaks in virNetClientProgramCall in libvirt 1.0.2
Product:	[Fedora] Fedora	Reporter:	Richard W.M. Jones <rjones>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	berrange, clalancette, crobinso, itamar, jforbes, jtomko, jyang, laine, libvirt-maint, mprivozn, veillard, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-28 22:09:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Richard W.M. Jones 2013-02-20 14:01:53 UTC

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'.

Comment 1 Daniel Berrangé 2013-02-20 14:09:47 UTC

Wierd. All these traces are saying "0 bytes" - so I'm not really sure what valgrind thinks is wrong here.

Comment 2 Richard W.M. Jones 2013-02-20 14:30:13 UTC

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.

Comment 3 Daniel Berrangé 2013-02-20 14:36:22 UTC

Hmm, I would have expected it to report '1 byte' leaked if calloc(0) returned non-NULL, but worth checking I guess.

Comment 4 Ján Tomko 2013-02-20 15:04:12 UTC

I remember seeing a similar valgrind log on the list
https://www.redhat.com/archives/libvir-list/2013-February/msg00813.html

Comment 5 Michal Privoznik 2013-02-20 17:03:20 UTC

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.

Comment 6 Cole Robinson 2013-02-28 22:09:04 UTC

Just closing as UPSTREAM, this is minor and will be fixed with the next libvirt update in rawhide