[Bug 1024848] Re: mission-control-5 assert failure: *** glibc detected *** /usr/lib/telepathy/mission-control-5: double free or corruption (out): 0x0000000001756790 ***

[Bug Watch Updater]

Launchpad has imported 11 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=51842.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2012-07-07T21:47:46+00:00 Laurent Bigonville wrote:

Created attachment 63953
Valgrind

Hi,

I've several crash that are affecting me quite often (bug #51559 and
#51813)

I was running MC in valgrind and it seems it tries to access freed
memory in several occasions

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/0

------------------------------------------------------------------------
On 2012-07-09T17:25:56+00:00 Xavier Claessens wrote:

*** Bug 51454 has been marked as a duplicate of this bug. ***

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/1

------------------------------------------------------------------------
On 2012-07-09T17:31:46+00:00 Xavier Claessens wrote:

I've understood how this can happen:
in mcd-account-manager-default.c::_delete_from_keyring() it does:
      gchar *removed = g_strdup (account);
      g_hash_table_insert (amd->removed_accounts, removed, removed);

So what happens if the account is already in the hash table? Doc says:
"""
If the key already exists in the GHashTable its current value is replaced with the new value. If you supplied a value_destroy_func when creating the GHashTable, the old value is freed using that function. If you supplied a key_destroy_func when creating the GHashTable, the passed key is freed using that function.
"""

Since @removed is passed both as value and key, it gets inserted as
value but freed as key => we get a freed string as value!!

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/2

------------------------------------------------------------------------
On 2012-07-09T17:38:55+00:00 Xavier Claessens wrote:

Created attachment 64015
McdAccountManagerDefault: Fix a possible double free

If the account is already in the hashtable, g_hash_table_insert()
will set @removed as value, but free it since the key already in
the table is kept.

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/3

------------------------------------------------------------------------
On 2012-07-09T17:41:03+00:00 Xavier Claessens wrote:

Note that we could use g_hash_table_add() but that's new in glib 2.32
and MC still depends on 2.30. In master that's certainly OK, but
probably not for backporting in stable branch.

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/4

------------------------------------------------------------------------
On 2012-07-09T17:48:16+00:00 Jonny-lamb wrote:

Can you write a test for this perchance?

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/5

------------------------------------------------------------------------
On 2012-07-09T18:28:47+00:00 Laurent Bigonville wrote:

Doesn't it sound weird that MC is actually calling
_delete_from_keyring() function from
mcd_account_connection_self_nickname_changed_cb() ?

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/6

------------------------------------------------------------------------
On 2012-07-09T18:33:26+00:00 Xavier Claessens wrote:

Right, that looks suspicious. Also I'm starting to wonder if I really
fixed this issue.

As explained above, we can end with freed strings as value in the hash
table, but the value is never used... only the key is. And I don't see
how the key could be invalid.

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/7

------------------------------------------------------------------------
On 2012-07-09T20:52:56+00:00 Xavier Claessens wrote:

Ok, it continuously wants to remove *GOA* accounts from default storage
(keyring and .mission-control/accounts/accounts.cfg), because they are
not stored there.

My patch really fix the issue, I was able reproduce the valgrind logs
and with the patch I can't anymore.

I've absolutely no idea how to test this behaviour though, that involves
having accounts on other storage than the default one... and even then
you need valgrind to catch the problem, it does not always crash.

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/8

------------------------------------------------------------------------
On 2012-07-09T21:05:57+00:00 Jonny-lamb wrote:

MC already has a test account storage -- the diverted plugin.

All accounts will be saved in the non-default account storage unless the
account parameter starts with 'dontdivert'.

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/9

------------------------------------------------------------------------
On 2012-07-11T17:12:26+00:00 Xavier Claessens wrote:

I couldn't reproduce this in a unit test. I've spent enough time on this
1 line fix, if someone knows how MC tests works please do it :-)

Reply at: https://bugs.launchpad.net/mission-
control-5/+bug/1024848/comments/10


** Changed in: mission-control-5
       Status: Unknown => Fix Released

** Changed in: mission-control-5
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of
Telepathy, which is subscribed to telepathy-mission-control-5 in Ubuntu.
https://bugs.launchpad.net/bugs/1024848

Title:
  mission-control-5 assert failure: *** glibc detected ***
  /usr/lib/telepathy/mission-control-5: double free or corruption (out):
  0x0000000001756790 ***

To manage notifications about this bug go to:
https://bugs.launchpad.net/mission-control-5/+bug/1024848/+subscriptions