[Bug 79827] MC crashes when GOA is restarted

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jun 9 04:56:16 PDT 2014


https://bugs.freedesktop.org/show_bug.cgi?id=79827

--- Comment #3 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> ---
When GOA is restarted, here is what happens from MC's pov:
- Each GOA account is removed
- Each GOA account is created

We are hitting this assertion because the old McdAccount is still alive when
the new one is created for the account.

There are two reasons for this:

- In mcd_account_delete_async() we call _mcd_account_set_enabled () to disable
enabled accounts. This calls mcd_account_changed_property() which is going to
do this change async and so ref the McdAccount will doing so.

- mcd_account_delete_async() uses a GTask internally; it doesn't really need it
as all its work in sync but it's a convenient object to report error or success
to the user callback. But when it calls g_task_return_boolean() GTask will
internally calls the user callback in an idle callback and so keeping its
source object (the McdAccount) alive longer.

We could solve the first problem by not updating the Account.Enabled property
of the account when deleting it. Does it really make sense to update it for an
account which is about to disappear anyway?

An easy hackish solution for the second issue could be to use
GSimpleAsyncResult instead of GTask with g_simple_async_result_complete() so
the user callback is called right away.

Or maybe mcd_account_delete_async() should just be a sync function as it
doesn't really do any async work anyway?

Another option could be to unregister the Account D-Bus object earlier in the
deletion process to avoid such tricky issues.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the telepathy-bugs mailing list