Bug 620345

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.

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.

rh620345-memleak-fixes.patch

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.

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

Created attachment 480440 [details]
old version (-12)

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..

libvirt-0.8.1-27.el6.x86_64 

can this be caused by this slightly older libvirt?

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

FYI, the build is:
RHEL6.1-20110202.n.0

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.

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

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.

    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.

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