Bug 1008979

Summary: possible memory leaks in libvirt detected
Product: Red Hat Enterprise Linux 6 Reporter: Tomas Pelka <tpelka>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.5CC: acathrow, jdenemar
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-17 13:18:20 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:
Attachments:
Description Flags
valgrind output none

Description Tomas Pelka 2013-09-17 12:35:48 UTC 
Description of problem:
see attached vlagrind output

Version-Release number of selected component (if applicable):
libvirt-0.10.2-24.el6

How reproducible:
100%

Steps to Reproduce:
1. valgrind --leak-check=full --show-reachable=yes -v --log-file=libvirt.leaks /usr/sbin/libvirtd
2.
3.

Actual results:
==17326== LEAK SUMMARY:
==17326==    definitely lost: 46 bytes in 2 blocks
==17326==    indirectly lost: 0 bytes in 0 blocks
==17326==      possibly lost: 88 bytes in 2 blocks
==17326==    still reachable: 149,774 bytes in 1,610 blocks
==17326==         suppressed: 0 bytes in 0 blocks
==17326== 
==17326== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 8 from 6)

Expected results:


Additional info:
Comment 1 Tomas Pelka 2013-09-17 12:36:25 UTC 
Created attachment 798799 [details]
valgrind output
Comment 2 Jiri Denemark 2013-09-17 13:00:22 UTC 
There are only 2 blocks of definitely lost memory:

==17371== 21 bytes in 1 blocks are definitely lost in loss record 19 of 127
==17371==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==17371==    by 0x5C68744: PR_GetLibraryFilePathname (prlink.c:1346)
==17371==    by 0x5EE28E5: PR_GetLibraryFilePathname_stub (stubs.c:363)
==17371==    by 0x5EBE6A8: BLAPI_FIPSInstalled (shvfy.c:286)
==17371==    by 0x5EA970A: fips_startup_tests (fipstest.c:2175)
==17371==    by 0x5EE7FD5: ??? (in /lib64/libfreebl3.so)
==17371==    by 0x5E969DA: ??? (in /lib64/libfreebl3.so)

and

==17371== 25 bytes in 1 blocks are definitely lost in loss record 34 of 127
==17371==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==17371==    by 0x5634A16: PORT_Alloc_Util (secport.c:78)
==17371==    by 0x5EBE612: mkCheckFileName (shvfy.c:231)
==17371==    by 0x5EBE6C7: BLAPI_FIPSInstalled (shvfy.c:293)
==17371==    by 0x5EA970A: fips_startup_tests (fipstest.c:2175)
==17371==    by 0x5EE7FD5: ??? (in /lib64/libfreebl3.so)
==17371==    by 0x5E969DA: ??? (in /lib64/libfreebl3.so)
Comment 3 Jiri Denemark 2013-09-17 13:18:20 UTC 
The two possibly lost blocks are similar so there's no detected leak in libvirtd. Also libvirtd is a daemon that tends to initialize some data structures at startup and keep them forever so there's not much sense in reporting reachable memory blocks.