Bug 620345 - multiple memory leaks in libnl
multiple memory leaks in libnl
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libnl (Show other bugs)
6.0
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Dan Williams
desktop-bugs@redhat.com
: Patch, ZStream
Depends On:
Blocks: 620334 656795 676327 682240
  Show dependency treegraph
 
Reported: 2010-08-02 05:25 EDT by ritz
Modified: 2011-05-19 10:29 EDT (History)
10 users (show)

See Also:
Fixed In Version: libnl-1.1-13.el6
Doc Type: Bug Fix
Doc Text:
When a domain started under libvirt, a memory leak was triggered from the libnl library because libnl continued to use memory no longer in use. Memory leaks in libnl are now fixed and libnl releases memory after it completes usage.
Story Points: ---
Clone Of:
: 682240 (view as bug list)
Environment:
Last Closed: 2011-05-19 10:29:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch based on upstream (5.01 KB, patch)
2010-08-02 05:25 EDT, ritz
no flags Details | Diff
old version (-12) (18.60 KB, text/plain)
2011-02-23 07:36 EST, Vladimir Benes
no flags Details
new version (-12.el6_0.1) (18.41 KB, text/plain)
2011-02-23 07:41 EST, Vladimir Benes
no flags Details
valgrind output (22.05 KB, text/plain)
2011-02-25 10:17 EST, Vladimir Benes
no flags Details

  None (edit)
Description ritz 2010-08-02 05:25:19 EDT
Created attachment 435982 [details]
patch based on upstream

Description of problem:
mem leak, patch attached.


commit ef50a38fbd8682a5c9efd559e7db68664977f080
Author: Thomas Graf <tgr@lsx.localdomain>
Date:   Thu May 15 13:45:41 2008 +0200

    Fix memory leaks when sending of message failed
    
    Various callers of nl_send_auto_complete() failed to
    free the allocated message when an error was reported.

commit b64f15d6f947839236fa276d473d238f8c9b9d57
Author: Patrick McHardy <kaber@trash.net>
Date:   Fri Jan 18 17:55:49 2008 +0100

    [LIBNL]: Fix minor memleaks on exit
    
    Make valgrind happy ...
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
Comment 1 Eric Blake 2010-11-24 17:35:59 EST
Can we get this in? It is making leak detection in other projects, like libvirt, more painful than it should be, because of sifting through many indirect leaks caused by libnl.
Comment 2 RHEL Product and Program Management 2011-01-07 11:04:26 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 12 Dan Williams 2011-02-08 10:24:51 EST
rh620345-memleak-fixes.patch
Comment 15 Eric Blake 2011-02-21 12:21:17 EST
Using:
libvirt-0.8.7-7.el6.x86_64
libnl-1.1-12.el6.x86_64

I see the libnl leak affecting libvirt using these steps:
# service libvirtd stop
# valgrind --leak-check=full /usr/sbin/libvirtd &
# sleep 30 && kill $!

Not all of the leaks shown with that combination are related to libnl, but it does include at least the following:

==10445== 5 bytes in 1 blocks are possibly lost in loss record 10 of 413
==10445==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==10445==    by 0x3297C7FD91: strdup (in /lib64/libc-2.12.so)
==10445==    by 0x32A682BDAB: add_proto_name (netlink-local.h:136)
==10445==    by 0x32A682BE74: init_proto_names (route_utils.c:103)
==10445==    by 0x32A683A485: ??? (in /lib64/libnl.so.1.1)
==10445==    by 0x32A68134FA: ??? (in /lib64/libnl.so.1.1)
==10445== 
==10445== 5 bytes in 1 blocks are possibly lost in loss record 11 of 413
==10445==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==10445==    by 0x3297C7FD91: strdup (in /lib64/libc-2.12.so)
==10445==    by 0x32A682BB8B: add_routing_table_name (netlink-local.h:136)
==10445==    by 0x32A682BC43: init_routing_table_names (route_utils.c:62)
==10445==    by 0x32A683A485: ??? (in /lib64/libnl.so.1.1)
==10445==    by 0x32A68134FA: ??? (in /lib64/libnl.so.1.1)
==10445== 
==10445== 6 bytes in 1 blocks are possibly lost in loss record 24 of 413
==10445==    at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==10445==    by 0x3297C7FD91: strdup (in /lib64/libc-2.12.so)
==10445==    by 0x32A682BB8B: add_routing_table_name (netlink-local.h:136)
==10445==    by 0x32A683A485: ??? (in /lib64/libnl.so.1.1)
==10445==    by 0x32A68134FA: ??? (in /lib64/libnl.so.1.1)

If upgrading to libnl-1.1-13.el6.x86_64 makes those entries disappear, then the problem has been resolved.  If not, then I can spend time trying to isolate exactly which libnl calls libvirt is making which still leak.
Comment 16 Vladimir Benes 2011-02-23 05:54:46 EST
I can still see this when executing this command 

virt-install --name mach --ram 512 --nodisk --cdrom http://download.devel/released/F-14/GOLD/Live/i686/Fedora-14-i686-Live-Desktop.iso

while valgrind --leak-check=full libvirtd running

==11503== 7 bytes in 1 blocks are possibly lost in loss record 216 of 2,960
==11503==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==11503==    by 0x39CBC7FD51: strdup (in /lib64/libc-2.12.so)
==11503==    by 0x4C7D0CB: add_proto_name (netlink-local.h:136)
==11503==    by 0x4C7D161: init_proto_names (route_utils.c:105)
==11503==    by 0x4C8B7A5: ??? (in /lib64/libnl.so.1.1)
==11503==    by 0x4C6452A: ??? (in /lib64/libnl.so.1.1)
==11503== 
==11503== 7 bytes in 1 blocks are possibly lost in loss record 217 of 2,960
==11503==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==11503==    by 0x39CBC7FD51: strdup (in /lib64/libc-2.12.so)
==11503==    by 0x4C7D0CB: add_proto_name (netlink-local.h:136)
==11503==    by 0x4C7D183: init_proto_names (route_utils.c:107)
==11503==    by 0x4C8B7A5: ??? (in /lib64/libnl.so.1.1)
==11503==    by 0x4C6452A: ??? (in /lib64/libnl.so.1.1)
==11503== 
==11503== 7 bytes in 1 blocks are possibly lost in loss record 218 of 2,960
==11503==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==11503==    by 0x39CBC7FD51: strdup (in /lib64/libc-2.12.so)
==11503==    by 0x4C7D0CB: add_proto_name (netlink-local.h:136)
==11503==    by 0x4C8B7A5: ??? (in /lib64/libnl.so.1.1)
==11503==    by 0x4C6452A: ??? (in /lib64/libnl.so.1.1)
==11503== 
==11503== 7 bytes in 1 blocks are possibly lost in loss record 219 of 2,960
==11503==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==11503==    by 0x39CBC7FD51: strdup (in /lib64/libc-2.12.so)
==11503==    by 0x4C7CDEB: add_routing_table_name (netlink-local.h:136)
==11503==    by 0x4C7CE81: init_routing_table_names (route_utils.c:60)
==11503==    by 0x4C8B7A5: ??? (in /lib64/libnl.so.1.1)
==11503==    by 0x4C6452A: ??? (in /lib64/libnl.so.1.1)


could you please look at it?

version:
libnl-1.1-12.el6_0.1.x86_64
Comment 17 Vladimir Benes 2011-02-23 07:36:59 EST
Created attachment 480440 [details]
old version (-12)
Comment 18 Vladimir Benes 2011-02-23 07:41:58 EST
Created attachment 480442 [details]
new version (-12.el6_0.1)

the behaviour seems better as fewer bytes are definitely lost but there are still some of them caused by libnl..
Comment 19 Vladimir Benes 2011-02-23 07:45:45 EST
libvirt-0.8.1-27.el6.x86_64 

can this be caused by this slightly older libvirt?
Comment 20 Wayne Sun 2011-02-24 22:50:43 EST
No possibly lost problems with libnl-1.1-13. 

Packages:
libvirt-0.8.7-8.el6.x86_64
valgrind-3.6.0-3.el6.x86_64
qemu-kvm-0.12.1.2-2.143.el6.x86_64
kernel-2.6.32-118.el6.x86_64
libnl-1.1-13.el6.x86_64


Steps:
1. service libvirtd stop
2. valgrind --leak-check=full /usr/sbin/libvirtd&
3. sleep 30 && kill $!

Actual results:
==9370== HEAP SUMMARY:
==9370==     in use at exit: 485,193 bytes in 7,167 blocks
==9370==   total heap usage: 82,835 allocs, 75,668 frees, 364,022,509 bytes
allocated
==9370== 
==9370== LEAK SUMMARY:
==9370==    definitely lost: 0 bytes in 0 blocks
==9370==    indirectly lost: 0 bytes in 0 blocks
==9370==      possibly lost: 0 bytes in 0 blocks
==9370==    still reachable: 485,193 bytes in 7,167 blocks
==9370==         suppressed: 0 bytes in 0 blocks
==9370== Reachable blocks (those to which a pointer was found) are not shown.
==9370== To see them, rerun with: --leak-check=full --show-reachable=yes
==9370== 
==9370== For counts of detected and suppressed errors, rerun with: -v
==9370== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 30 from 9)

[1]+  Done                    valgrind --leak-check=full /usr/sbin/libvirtd
Comment 21 Wayne Sun 2011-02-24 22:54:35 EST
FYI, the build is:
RHEL6.1-20110202.n.0
Comment 22 Vladimir Benes 2011-02-25 10:17:24 EST
Created attachment 481015 [details]
valgrind output

While I can see no leaks during domain start I can see some in guest start (see attachment) should I file another bug or can they also be fixed via this bugzilla? I think it's worth it as no more testing would be needed.
Comment 23 Vladimir Benes 2011-03-03 12:27:34 EST
Hi Eric,
I can still see some leaks (during guest boot up) but those from domain start are fixed. Are you OK with this fix or do you want some more work in this area? see the attachment from comment above. 
We need to ship libnl quickly as it blocks SPICE team now.

cheers,
Vlad
Comment 24 Eric Blake 2011-03-04 10:31:16 EST
Let's go ahead and mark this fixed, as it does avoid the leaks as originally reported in this bug.  I also still see some noise from valgrind from libvirtd startup, but it is marked as possibly lost rather than definitely lost, and I haven't narrowed into a reproducible test case to pinpoint exactly which libnl calls are the culprit (or even if it is libvirt's usage patterns at fault instead); I will open a new BZ once I have further narrowed that down, since it is unrelated to the original leak in the subject of this bug.
Comment 27 Misha H. Ali 2011-04-19 06:11:46 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When a domain started under libvirt, a memory leak was triggered from the libnl library because libnl continued to use memory no longer in use. Memory leaks in libnl are now fixed and libnl releases memory after it completes usage.
Comment 28 errata-xmlrpc 2011-05-19 10:29:47 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0795.html

Note You need to log in before you can comment on or make changes to this bug.