Hi,
This should fix g_dbus_add_signal_watch when a service like org.bluez is given.
--
Luiz Augusto von Dentz
Computer Engineer
Hi,
On Wed, Feb 17, 2010 at 6:08 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Marcel,
>
> On Wed, Feb 17, 2010 at 12:00 PM, Marcel Holtmann <[email protected]> wrote:
>> Hi Luiz,
>>
>>> @Marcel: So before you apply this you should really apply Vinicius
>>> patch to the rest of projects: bluez, ofono, connman...
>>
>> has been applied to all projects now. Please resend your other patch
>> based on the latest tree.
>
> Resending the patch and also add another one to make sure we cancel
> any pending operation during watch removal.
Resending with the latests fixes to make hfp ofono plugin to work properly.
--
Luiz Augusto von Dentz
Computer Engineer
Hi Marcel,
On Wed, Feb 17, 2010 at 12:00 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Luiz,
>
>> @Marcel: So before you apply this you should really apply Vinicius
>> patch to the rest of projects: bluez, ofono, connman...
>
> has been applied to all projects now. Please resend your other patch
> based on the latest tree.
Resending the patch and also add another one to make sure we cancel
any pending operation during watch removal.
--
Luiz Augusto von Dentz
Computer Engineer
Hi Luiz,
> @Marcel: So before you apply this you should really apply Vinicius
> patch to the rest of projects: bluez, ofono, connman...
has been applied to all projects now. Please resend your other patch
based on the latest tree.
Regards
Marcel
Hi Vinicius,
On Wed, Feb 17, 2010 at 2:34 AM, Vinicius Gomes
<[email protected]> wrote:
> Hi Luiz,
>
> On Tue, Feb 16, 2010 at 12:58 PM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi Marcel,
>>
>> On Tue, Feb 16, 2010 at 5:37 PM, Marcel Holtmann <[email protected]> w=
rote:
>>> Hi Luiz,
>>>
>>>> > This should fix g_dbus_add_signal_watch when a service like org.blue=
z is given.
>>>>
>>>>
>>>> Updating since the last one was broken.
>>>
>>> I also think that in check_service() we actually have a missing call to
>>> dbus_pending_unref(). That would cause a memory leak.
>>
>> There is a call to =A0dbus_pending_call_unref on check_service after
>> dbus_pending_call_set_notify, which I took a look and seems correct
>> but we have another problem there since we never cancel the pending
>> call if the filter is unregister. Anyway there is a leak on
>> service_reply where I don't call dbus_message_unref, so I will come up
>> with another update soon.
>>
>
> This is fixed on obexd, but as far as I could see it is not (yet?)
> applied on the other users
> of gdbus.
Hmm, that why I see it, I used obexd to test this not bluetoothd as
(probably) Marcel did, anyway we still need to store and cancel the
pending call if we really want the watches to be truly cancelable.
> And, from what I tested the greater problem is that the timeout of the
> pending call would still
> trigger. This would cause libdbus to terminate the application, if
> libdbus was built with debug enabled,
> because one assert would fail (the message is "trying to remove an
> nonexistent timeout" or
> =A0something like it). The timeout still triggering is the reason we
> don't see the pending call leaking.
@Marcel: So before you apply this you should really apply Vinicius
patch to the rest of projects: bluez, ofono, connman...
--=20
Luiz Augusto von Dentz
Computer Engineer
Hi Luiz,
On Tue, Feb 16, 2010 at 12:58 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Marcel,
>
> On Tue, Feb 16, 2010 at 5:37 PM, Marcel Holtmann <[email protected]> wr=
ote:
>> Hi Luiz,
>>
>>> > This should fix g_dbus_add_signal_watch when a service like org.bluez=
is given.
>>>
>>>
>>> Updating since the last one was broken.
>>
>> I also think that in check_service() we actually have a missing call to
>> dbus_pending_unref(). That would cause a memory leak.
>
> There is a call to =C2=A0dbus_pending_call_unref on check_service after
> dbus_pending_call_set_notify, which I took a look and seems correct
> but we have another problem there since we never cancel the pending
> call if the filter is unregister. Anyway there is a leak on
> service_reply where I don't call dbus_message_unref, so I will come up
> with another update soon.
>
This is fixed on obexd, but as far as I could see it is not (yet?)
applied on the other users
of gdbus.
And, from what I tested the greater problem is that the timeout of the
pending call would still
trigger. This would cause libdbus to terminate the application, if
libdbus was built with debug enabled,
because one assert would fail (the message is "trying to remove an
nonexistent timeout" or
something like it). The timeout still triggering is the reason we
don't see the pending call leaking.
> --
> Luiz Augusto von Dentz
> Computer Engineer
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=
" in
> the body of a message to [email protected]
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
>
Cheers,
--=20
Vinicius Gomes
INdT - Instituto Nokia de Tecnologia
Hi,
On Tue, Feb 16, 2010 at 5:58 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Marcel,
>
> On Tue, Feb 16, 2010 at 5:37 PM, Marcel Holtmann <[email protected]> wrote:
>> Hi Luiz,
>>
>>> > This should fix g_dbus_add_signal_watch when a service like org.bluez is given.
>>>
>>>
>>> Updating since the last one was broken.
>>
>> I also think that in check_service() we actually have a missing call to
>> dbus_pending_unref(). That would cause a memory leak.
>
> There is a call to ?dbus_pending_call_unref on check_service after
> dbus_pending_call_set_notify, which I took a look and seems correct
> but we have another problem there since we never cancel the pending
> call if the filter is unregister. Anyway there is a leak on
> service_reply where I don't call dbus_message_unref, so I will come up
> with another update soon.
Now with the memory leaks fixed.
--
Luiz Augusto von Dentz
Computer Engineer
Hi Marcel,
On Tue, Feb 16, 2010 at 5:37 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Luiz,
>
>> > This should fix g_dbus_add_signal_watch when a service like org.bluez is given.
>>
>>
>> Updating since the last one was broken.
>
> I also think that in check_service() we actually have a missing call to
> dbus_pending_unref(). That would cause a memory leak.
There is a call to dbus_pending_call_unref on check_service after
dbus_pending_call_set_notify, which I took a look and seems correct
but we have another problem there since we never cancel the pending
call if the filter is unregister. Anyway there is a leak on
service_reply where I don't call dbus_message_unref, so I will come up
with another update soon.
--
Luiz Augusto von Dentz
Computer Engineer
Hi Luiz,
> > This should fix g_dbus_add_signal_watch when a service like org.bluez is given.
>
>
> Updating since the last one was broken.
I also think that in check_service() we actually have a missing call to
dbus_pending_unref(). That would cause a memory leak.
Regards
Marcel
Hi,
On Tue, Feb 16, 2010 at 4:59 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi,
>
> This should fix g_dbus_add_signal_watch when a service like org.bluez is given.
Updating since the last one was broken.
--
Luiz Augusto von Dentz
Computer Engineer