[libvirt] [PATCH] network: avoid memory leak on cleanup

Osier Yang jyang at redhat.com
Mon Jul 18 03:25:57 UTC 2011


于 2011年07月18日 11:01, Alex Jia 写道:
> On 07/18/2011 12:35 AM, Alex Jia wrote:
>> Hi Daniel,
>> # rpm -q libvirt
>> libvirt-0.9.3-3.el6.x86_64
>>
>> Regards,
>> Alex
>>
>>
>> ----- Original Message -----
>> From: "Daniel P. Berrange"<berrange at redhat.com>
>> To: "Alex Jia"<ajia at redhat.com>
>> Cc: "Matthias Bolte"<matthias.bolte at googlemail.com>, 
>> libvir-list at redhat.com
>> Sent: Friday, July 15, 2011 6:12:17 PM
>> Subject: Re: [libvirt] [PATCH] network: avoid memory leak on cleanup
>>
>> On Fri, Jul 15, 2011 at 03:03:07PM +0800, Alex Jia wrote:
>>> On 07/15/2011 02:49 PM, Matthias Bolte wrote:
>>>> 2011/7/15<ajia at redhat.com>:
>>>>> * src/network/bridge_driver.c: Fix memory leak on cleanup section 
>>>>> from
>>>>> networkGetBridgeName function.
>>>>> ---
>>>>> src/network/bridge_driver.c | 3 ++-
>>>>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/src/network/bridge_driver.c 
>>>>> b/src/network/bridge_driver.c
>>>>> index 0a12bc0..59e780d 100644
>>>>> --- a/src/network/bridge_driver.c
>>>>> +++ b/src/network/bridge_driver.c
>>>>> @@ -2474,7 +2474,8 @@ static char 
>>>>> *networkGetBridgeName(virNetworkPtr net) {
>>>>> cleanup:
>>>>> if (network)
>>>>> virNetworkObjUnlock(network);
>>>>> - return bridge;
>>>>> + VIR_FREE(bridge);
>>>>> + return NULL;
>>>>> }
>>>>>
>>>>> static int networkGetAutostart(virNetworkPtr net,
>>>> NACK. Now networkGetBridgeName returns NULL always, that's wrong.
>>>>
>>>> Why do you think that there is a leak?
>>>>
>>> Detected in valgrind run:
>>> ==9020== 7 bytes in 1 blocks are definitely lost in loss record 1 of 26
>>> ==9020== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
>>> ==9020== by 0x386A314B3D: xdr_string (in /lib64/libc-2.12.so)
>>> ==9020== by 0x4CFC0AD: xdr_remote_nonnull_string (remote_protocol.c:30)
>>> ==9020== by 0x4CFCC08: xdr_remote_network_get_bridge_name_ret 
>>> (remote_protocol.c:1999)
>>> ==9020== by 0x4D06FC1: virNetMessageDecodePayload (virnetmessage.c:286)
>>> ==9020== by 0x4D03235: virNetClientProgramCall 
>>> (virnetclientprogram.c:318)
>>> ==9020== by 0x4CE7262: call (remote_driver.c:3925)
>>> ==9020== by 0x4CED8D2: remoteNetworkGetBridgeName 
>>> (remote_client_bodies.h:3384)
>>> ==9020== by 0x4CC494E: virNetworkGetBridgeName (libvirt.c:8503)
>>> ==9020== by 0x40F654: cmdNetworkInfo (virsh.c:5015)
>>> ==9020== by 0x410D02: vshCommandRun (virsh.c:12738)
>>> ==9020== by 0x41F2D5: main (virsh.c:14084)
>>> ==9020==
>>> ==9020== 10 bytes in 1 blocks are definitely lost in loss record 3 
>>> of 26
>>> ==9020== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
>>> ==9020== by 0x386A27F8A1: strdup (in /lib64/libc-2.12.so)
>>> ==9020== by 0x4CF508B: doRemoteOpen (remote_driver.c:364)
>>> ==9020== by 0x4CF6E8F: remoteOpen (remote_driver.c:800)
>>> ==9020== by 0x4CCB384: do_open (libvirt.c:1054)
>>> ==9020== by 0x4CCBEB5: virConnectOpenAuth (libvirt.c:1280)
>>> ==9020== by 0x410BC0: vshReconnect (virsh.c:589)
>>> ==9020== by 0x410DCF: vshCommandRun (virsh.c:12733)
>>> ==9020== by 0x41F2D5: main (virsh.c:14084)
>>> ==9020==
>>> ==9020== 56 (24 direct, 32 indirect) bytes in 1 blocks are 
>>> definitely lost in loss record 17 of 26
>>> ==9020== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
>>> ==9020== by 0x4C686ED: virAlloc (memory.c:101)
>>> ==9020== by 0x4C96870: virDomainEventStateNew (domain_event.c:578)
>>> ==9020== by 0x4CF5A8E: doRemoteOpen (remote_driver.c:658)
>>> ==9020== by 0x4CF6E8F: remoteOpen (remote_driver.c:800)
>>> ==9020== by 0x4CCB384: do_open (libvirt.c:1054)
>>> ==9020== by 0x4CCBEB5: virConnectOpenAuth (libvirt.c:1280)
>>> ==9020== by 0x410BC0: vshReconnect (virsh.c:589)
>>> ==9020== by 0x410DCF: vshCommandRun (virsh.c:12733)
>>> ==9020== by 0x41F2D5: main (virsh.c:14084)
>> What version of libvirt did you test this on ? These were leaks
>> in the 0.9.3 release, but current GIT has fixed them
>>
>>
>> Daniel
> Now, it's fine for libvirt-0.9.3-5.el6.x86_64, I haven't found remote 
> leak again.
>
> Regards,
> Alex

You should always use upstream libvirt to make patches for upstream.

>
> -- 
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list




More information about the libvir-list mailing list