RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 620345 - multiple memory leaks in libnl
Summary: multiple memory leaks in libnl
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libnl
Version: 6.0
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Dan Williams
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 620334 656795 676327 682240
TreeView+ depends on / blocked
 
Reported: 2010-08-02 09:25 UTC by ritz
Modified: 2011-05-19 14:29 UTC (History)
10 users (show)

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.
Clone Of:
: 682240 (view as bug list)
Environment:
Last Closed: 2011-05-19 14:29:47 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0795 0 normal SHIPPED_LIVE libnl bug fix update 2011-05-18 18:08:09 UTC

Description ritz 2010-08-02 09:25:19 UTC
Created attachment 435982 [details]
patch based on upstream

Description of problem:
mem leak, patch attached.


commit ef50a38fbd8682a5c9efd559e7db68664977f080
Author: Thomas Graf <tgr>
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>
Date:   Fri Jan 18 17:55:49 2008 +0100

    [LIBNL]: Fix minor memleaks on exit
    
    Make valgrind happy ...
    
    Signed-off-by: Patrick McHardy <kaber>

Comment 1 Eric Blake 2010-11-24 22:35:59 UTC
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 Program Management 2011-01-07 16:04:26 UTC
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 15:24:51 UTC
rh620345-memleak-fixes.patch

Comment 15 Eric Blake 2011-02-21 17:21:17 UTC
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 10:54:46 UTC
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 12:36:59 UTC
Created attachment 480440 [details]
old version (-12)

Comment 18 Vladimir Benes 2011-02-23 12:41:58 UTC
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 12:45:45 UTC
libvirt-0.8.1-27.el6.x86_64 

can this be caused by this slightly older libvirt?

Comment 20 Wayne Sun 2011-02-25 03:50:43 UTC
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-25 03:54:35 UTC
FYI, the build is:
RHEL6.1-20110202.n.0

Comment 22 Vladimir Benes 2011-02-25 15:17:24 UTC
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 17:27:34 UTC
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 15:31:16 UTC
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 10:11:46 UTC
    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 14:29:47 UTC
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.