Created attachment 63253 [details]
Backtrace

I'm not sure this is 100% related, but sometimes, MC is crashing with the following backtrace.

Is it possible that MC is crashing mid-air and thus not connecting the next account in its list?

Mhhh

I think I've found the issue (and it's maybe PEBCAK)

"mc-tool show" was saying:

Connects: only when requested

I've set the auto-connect to on. Let's see if I can still reproduce this.

But, AFAIK mc was connecting some (gabble) accounts even if the auto-connect was not enabled.

I think empathy's MC plugin for GOA is racy. It does not wait for the "ready" function to be called before emitting signals. That could explain some issues...

ah, this is about tp-haze... sorry wrong bug then :)

I can get the issue even when not connecting. It's as if haze disconnects from the rest of the status:

snippet of output of various "mc-tool show":

HAZE:
Presences:
   Automatic: available (2) ""
     Current: available (2) "" <-------------------
   Requested: available (2) "" <-------------------
    Changing: no

GOA FBook:
Presences:
   Automatic: available (2) ""
     Current: dnd (6) ""
   Requested: busy (6) ""
    Changing: no

GOA GTalk:
Presences:
   Automatic: available (2) ""
     Current: dnd (6) ""
   Requested: busy (6) ""
    Changing: no

Created attachment 64315 [details]
Gnome Shell Me menu unaware of tp-haze

Gnome Shell menu seems to be unaware of tp-haze existence (see attached file). Is it normal?

I'm thinking the screenshot isn't clear: with only Haze enabled, Gnome Shell menu has a greyed out 'Available/Unavailable' menu, suggesting Haze isn't properly announcing to Gnome-Shell it is enabled.

How to reproduce:
1. Create any Haze account (tested with Yahoo and Windows Live (MSN))
2. Verify using Gnome-Shell menu, status changes to Busy with setting "Notifications off", to online with "Notifications on" and to offline with "Unavailable".
3. Logout and login (or reboot)
2. Verify using Gnome-Shell menu, status does NOT change to Busy with setting "Notifications off", to online with "Notifications on" and to offline with "Unavailable".

Other accounts (i.e., not Haze) work fine.

Actually login and logout is not enough, a reboot is required. I'm guessing some kind of call (D-Bus?) is made registering Haze with something when the Haze account is created (some "internal" state/component which survives a logout) but when the Haze account is read from a file such as the accounts' config it is not registered with such "internal" component.

Ok, it seems I was wrong.

I seem to have fixed the problem by having a .config/autostart/mission-control.desktop which has Exec=/usr/libexec/mission-control-5 .

Previously I would have Empathy starting at Gnome-Shell startup using a similar approach.

Considering that if I try something like
$ ./telepathyKillAllComponentes.sh ; empathy-accounts
empathy accounts will show only GOA accounts the first time it's run (but show all of them the second time) I'll guess forcing Empathy to start at Gnome-Shell startup was messing things up by exposing some kind of race condition.

Either that or one of the latest telepathy-glib updates did something for this.

Created attachment 70028 [details] [review]
Increase timeout

During this summer, Guillaume looked with me at this bug.

We found that one DBUS call was timing out, increasing the timeout was fixing this. He also thought that it was related to folks blocking gnome-shell.

Unfortunately, I'm still seeing this in gnome-shell 3.6 too. If I've understood correctly, this shouldn't happen anymore as folks has been decoupled out of gnome-shell.

The attached patch has been made against tp-mc 5.12.1

Comment on attachment 70028 [details] [review]
Increase timeout

Review of attachment 70028 [details] [review]:
-----------------------------------------------------------------

There are more instances of calls to introspect a client: I feel as though if we extend one, we should extend them all. (We shouldn't extend the timeout when we call HandleChannels or similar, though.)

In _mcd_client_proxy_get_interfaces_cb we call Get or GetAll 3 times.

In mcd_client_proxy_introspect there is a call to GetAll.

::: telepathy-mission-control-5-5.12.1/debian/patches/path_cassidy.patch
@@ +4,5 @@
> + 
> +         _mcd_client_proxy_inc_ready_lock (self);
> + 
> +-        tp_cli_dbus_properties_call_get (self, -1,
> ++        tp_cli_dbus_properties_call_get (self, G_MAXINT,

Strictly speaking, the infinite timeout is G_MAXINT32 (although they're numerically the same on any sane platform).

I'd prefer to use the named constant to make the meaning obvious:

#include <dbus/dbus.h>

#ifndef DBUS_TIMEOUT_INFINITE
/* dbus < 1.4.12 didn't have this */
# define DBUS_TIMEOUT_INFINITE G_MAXINT32
#endif

...

tp_cli_dbus_properties_call_get (self, DBUS_TIMEOUT_INFINITE, ...

(In reply to comment #11)
> We found that one DBUS call was timing out, increasing the timeout was
> fixing this.

It seems a vaguely reasonable thing to do, although I can't help thinking that any Client that doesn't respond to us within 25 seconds has bigger problems...

Can you get a dbus-monitor log from this call into a Client timing out?

> Unfortunately, I'm still seeing this in gnome-shell 3.6 too. If I've
> understood correctly, this shouldn't happen anymore as folks has been
> decoupled out of gnome-shell.

Yes, in 3.5.4.

MMMh... So I was a wrong, the patch I've proposed was about the notifications not being displayed in gnome-shell, not about the accounts being out of sync... sorry for the confusion :/

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/issues/56.