[PATCH v2] connection: Fix service refcount

Wang, Arron arron.wang at intel.com
Thu Jan 5 22:17:30 PST 2012


Hi Jukka,

>-----Original Message-----
>From: Jukka Rissanen [mailto:jukka.rissanen at linux.intel.com]
>Sent: Thursday, January 05, 2012 8:30 PM
>To: Wang, Arron
>Cc: Daniel Wagner; connman at connman.net
>Subject: Re: [PATCH v2] connection: Fix service refcount
>
>Hi Arron,
>
>On 01/05/2012 11:46 AM, Daniel Wagner wrote:
>> Hi,
>>
>> On Mon, Dec 19, 2011 at 03:00:17AM -0500, Yu A Wang wrote:
>>> Service may be refcount two times when add_gateway for both ipv4 and
>>> ipv6, we need to unref the service twice according when we have both
>>> ipv6 and ipv4 gateway
>>
>> I did not apply this one. The whole logic in
>> __connman_connection_gateway_remove() looks really funky. Since Jukka
>> has written that part I would like to have he's input :)
>>
>> cheers,
>> daniel
>>
>
>I tried to your patch and did some testing (with network that has both
>IPv4 and IPv6 active) but was unable to see any difference with or
>without your patch.
>
>I also put some debug prints where you unref the service and that part
>was never called (explains why I did not see any difference in valgrind
>output). If we miss the service unref, then I would expect that we see
>something wrong in valgrind output also but I have not yet seen any
>memory leaks because of the missing unref.
>
>So atm I have to say NACK to this patch unless you can provide
>instructions how to trigger the problem.

The first time I met this issue is connected with cellular network, but I 
can't reproduce it now. However I found another way to reproduce this issue:
1. connected with any network like Ethernet
2. set manual ipv6 address and gateway for the connected service
3. disable that technology, We will still have the Ethernet service due to 
service refcount unbalance

Thanks
Arron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 8614 bytes
Desc: not available
URL: <http://lists.connman.net/pipermail/connman/attachments/20120106/48243c8a/attachment.bin>


More information about the connman mailing list