Seems tp_account_manager_get_valid_accounts () returns a list containing something which is not a TpAccount.

Jonny: is that because the accounts manager is not prepared (cfr FIXME) ?

It seems to be a tp-glib bug. I opened https://bugs.freedesktop.org/show_bug.cgi?id=25117 so we can close this bug for now.

I don't see tp_account_manager_get_valid_accounts () in the backtrace. Did you call it but then return to the main loop without reffing the returned accounts? If so, please reopen and fix in Empathy.

(The hash table does contain reffed accounts, so at first glance I don't see how the accounts could possibly be invalid during the call to tp_account_manager_get_valid_accounts(); however, the accounts could be removed from the hash table during a later entry to the main loop, which would invalidate the pointers you had borrowed.)

Code is:

  accounts = tp_account_manager_get_valid_accounts (priv->account_manager);

  for (l = accounts; l != NULL; l = g_list_next (l))
    {
      TpAccount *account = TP_ACCOUNT (l->data);


and the crash occurs in the TP_ACCOUNT cast.
Note that there is a FIXME saying that the account mgr MAY not be ready; but that shouldn't return a list containiving invalid pointers, right?

... but what else do you do in the body of the loop? Anything that can cause an unref can cause a pointer in the list to become invalid.

One way to debug this would be to have a loop that asserts TP_IS_ACCOUNT and nothing else, immediately after the method call?

When the TpAM is not ready, it should indeed still not return invalid pointers; I don't see any evidence in the code that it would, though. It currently returns g_hash_table_get_values() from a hash table whose elements are reffed by the hash table, so they should all be valid regardless, unless something somewhere is doing an unbalanced unref?

Rahh got it. I assumed tp_account_manager_get_valid_accounts() returned a list of reffed accounts while it doesn't (I didn't write this code and naively assumed it was using this function the right way).

Sorry for wasting your time.

Created attachment 147916 [details] [review]
http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/log-crash-600800

 libempathy/empathy-log-store-empathy.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

I checked in all the place where this function is called and this one is the only one doing that stupid mistake.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.