Bug 1008619

Summary: libvirtd leaks memory in virSystemdEscapeName on domain startup
Product: Red Hat Enterprise Linux 7 Reporter: Ján Tomko <jtomko>
Component: libvirtAssignee: Ján Tomko <jtomko>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: 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:

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.