Bug 1008619

Summary:	libvirtd leaks memory in virSystemdEscapeName on domain startup
Product:	Red Hat Enterprise Linux 7	Reporter:	Ján Tomko <jtomko>
Component:	libvirt	Assignee:	Ján Tomko <jtomko>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	acathrow, hliu, mjenner
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	libvirt-1.1.1-6.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-06-13 10:25:47 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 Ján Tomko 2013-09-16 17:23:46 UTC

Description of problem:
When starting a domain, libvirtd leaks memory in virSystemdEscapeName

Version-Release number of selected component (if applicable):
libvirt-1.1.1-4.el7

How reproducible:
100 %

Steps to Reproduce:
1. run libvirtd under valgrind:
# valgrind --leak-check=full libvirtd

2. create a domain
virsh create /dev/stdin <<EOF
> <domain type='qemu'>
>   <name>duck</name>
>   <memory unit='MiB'>32</memory>
>   <os>
>     <type arch='x86_64' machine='pc'>hvm</type>
>   </os>
> </domain>
> EOF
Domain duck created from /dev/stdin

Actual results:

valgrind shows a leak in virSystemdEscapeName:
==21660== 1,003 bytes in 1 blocks are definitely lost in loss record 712 of 750
==21660==    at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21660==    by 0x4A08278: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21660==    by 0x508462F: virReallocN (viralloc.c:233)
==21660==    by 0x5086BA3: virBufferGrow (virbuffer.c:129)
==21660==    by 0x5086D71: virBufferAdd (virbuffer.c:165)
==21660==    by 0x5086DB7: virBufferAddChar (virbuffer.c:185)
==21660==    by 0x50C6B26: virSystemdEscapeName (virsystemd.c:67)
==21660==    by 0x50C6D22: virSystemdMakeSliceName (virsystemd.c:108)
==21660==    by 0x50C6ED1: virSystemdCreateMachine (virsystemd.c:165)
==21660==    by 0x508AFBD: virCgroupNewMachine (vircgroup.c:1708)
==21660==    by 0x1BA19201: qemuSetupCgroup (qemu_cgroup.c:667)
==21660==    by 0x1BA3045F: qemuProcessStart (qemu_process.c:3831)


Expected results:
virSystemdEscapeName doesn't leak

Additional info:
Upstream patch posted: https://www.redhat.com/archives/libvir-list/2013-September/msg00856.html

Comment 1 Ján Tomko 2013-09-16 17:32:45 UTC

Now pushed upstream:
commit 09b48562aac12387a5ff9ac2f27f9a60490f41ee
Author:     Ján Tomko <jtomko>
AuthorDate: 2013-09-16 15:27:42 +0200
Commit:     Ján Tomko <jtomko>
CommitDate: 2013-09-16 19:26:21 +0200

    Free slicename in virSystemdCreateMachine
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1008619
    
    1,003 bytes in 1 blocks are definitely lost in loss record 599 of 635
    ==404== by 0x50728A7: virBufferAddChar (virbuffer.c:185)
    ==404== by 0x50BC466: virSystemdEscapeName (virsystemd.c:67)
    ==404== by 0x50BC6B2: virSystemdMakeSliceName (virsystemd.c:108)
    ==404== by 0x50BC870: virSystemdCreateMachine (virsystemd.c:169)
    ==404== by 0x5078267: virCgroupNewMachine (vircgroup.c:1498)

git describe: v1.1.2-129-g09b4856 

Downstream patch posted:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2013-September/msg00496.html

Comment 3 Hao Liu 2013-09-22 10:08:33 UTC

This fix is VERIFIED:

Following steps in https://bugzilla.redhat.com/show_bug.cgi?id=1008619#c0

leak in virSystemdEscapeName can be reproduced in
libvirt-1.1.1-4.el7
and disappeared (among other leaks) in
libvirt-1.1.1-6.el7

Comment 4 Ludek Smid 2014-06-13 10:25:47 UTC

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.