Sometimes, after a connection error of some form occurs, libpurple segfaults in connection.c:purple_connection_disconnect_cb(), which is called via an idle callback. In particular, purple_account_get_password(account) fails because account is invalid. I believe this is because haze destroys the account on an idle callback set in response to ConnUiOps::disconnected, but does not remove the gc->disconnect_timeout callback. Either haze should cancel that callback (which seems broken), or should destroy the account in response to a later signal.
As far as I can tell, libpurple removes the timeout at the right time; there's no code path that can let haze's idle callback fire before libpurple's one has either run or been cancelled. So I can't see why this would happen, and I can't reproduce it any more.
If you supply incorrect credentials haze crashes on connection, every time. Shortly after (haze:20176): tp-glib-DEBUG: tp_base_connection_change_status: was 1, now 2, for reason 3 ** (haze:20176): DEBUG: haze_im_channel_factory_iface_close_all: closing im channels (haze:20176): tp-glib-DEBUG: tp_base_connection_change_status: emitting status-changed to 2, for reason 3 ** Message: [info] account: Disconnecting account 0x9261ee0 ** Message: [info] connection: Disconnecting connection 0x9265588 ** Message: [info] connection: Destroying connection 0x9265588 you dereference freed memory of some form, usually because the prpl is inspecting its info stored on the connection after it's destroyed.
fixed in head: http://git.collabora.co.uk/?p=telepathy-haze.git;a=commit;h=41a82cc4e33b646630203223c204ace8ae1d9f49
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.