Thanks for the patch!

The patch looks fine, but I'm wondering how we get into this situation at all. Could you find out where the assertion happens please?

You can do this by running GLib apps with G_DEBUG=fatal_warnings in gdb.

Here it is. There is a bug that trigger this error path obviously unrelated to this fix. If I remind well the issue is that the empathy-chat window is created but not shown and fails to get the account for the first attempt to connect to a channel (this is a new bug I have not yet digged thorougly nor reported). Then empathy-chat segfault due to the bug here.
WIth this patch empathy-chat stays waiting. Then a second attempt to access a channel succeed. Not good but better than crashing indefinitely.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3f06f19 in _tp_base_client_handle_channels (iface=0x881240, account_path=0x8ad9a0 "/org/freedesktop/Telepathy/Account/idle/irc/prahal20", 
    connection_path=0x8a0a80 "/org/freedesktop/Telepathy/Connection/idle/irc/prahal2_40irc_2egimp_2eorg0x205d500", channels_arr=0x8afc40, requests_arr=0x8afb80, 
    user_action_time=9223372036854775807, handler_info=0x8ab920, context=0x8602b0) at base-client.c:2338
2338	          DEBUG ("Failed to create TpChannel: %s", error->message);
(gdb) bt
#0  0x00007ffff3f06f19 in _tp_base_client_handle_channels (iface=0x881240, account_path=0x8ad9a0 "/org/freedesktop/Telepathy/Account/idle/irc/prahal20", 
    connection_path=0x8a0a80 "/org/freedesktop/Telepathy/Connection/idle/irc/prahal2_40irc_2egimp_2eorg0x205d500", channels_arr=0x8afc40, requests_arr=0x8afb80, 
    user_action_time=9223372036854775807, handler_info=0x8ab920, context=0x8602b0) at base-client.c:2338
#1  0x00007ffff403e38b in tp_svc_client_handler_handle_channels (self=0x881240, in_Account=0x8ad9a0 "/org/freedesktop/Telepathy/Account/idle/irc/prahal20", 
    in_Connection=0x8a0a80 "/org/freedesktop/Telepathy/Connection/idle/irc/prahal2_40irc_2egimp_2eorg0x205d500", in_Channels=0x8afc40, in_Requests_Satisfied=0x8afb80, 
    in_User_Action_Time=9223372036854775807, in_Handler_Info=0x8ab920, context=0x8602b0) at _gen/tp-svc-client.c:238
#2  0x00007fffe2241e54 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#3  0x00007fffe2241875 in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#4  0x00007fffee2b4b07 in g_cclosure_marshal_generic (closure=0x7fffffffbf70, return_gvalue=0x0, n_param_values=8, param_values=0x8ad8d0, invocation_hint=0x0, marshal_data=0x7ffff403e313)
    at gclosure.c:1454
#5  0x00007ffff63de4a8 in ?? () from /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2
#6  0x00007ffff61a8299 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#7  0x00007ffff619a425 in dbus_connection_dispatch () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#8  0x00007ffff63db735 in ?? () from /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2
#9  0x00007fffedfadb09 in g_main_dispatch (context=0x747890) at gmain.c:2539
#10 0x00007fffedfae7ce in g_main_context_dispatch (context=0x747890) at gmain.c:3075
#11 0x00007fffedfae9b1 in g_main_context_iterate (context=0x747890, block=1, dispatch=1, self=0x852700) at gmain.c:3146
#12 0x00007fffedfaea75 in g_main_context_iteration (context=0x747890, may_block=1) at gmain.c:3207
#13 0x00007fffee5b7b77 in g_application_run (application=0x85d040, argc=1, argv=0x7fffffffc648) at gapplication.c:1571
#14 0x000000000043a7e9 in main (argc=1, argv=0x7fffffffc648) at empathy-chat.c:164
(gdb) l
2333	
2334	      channel = ensure_channel (self, connection, chan_path, chan_props,
2335	          &error);
2336	      if (channel == NULL)
2337	        {
2338	          DEBUG ("Failed to create TpChannel: %s", error->message);
2339	          goto out;
2340	        }
2341	
2342	      g_ptr_array_add (channels, channel);


with log showing:
Process /opt/gnome/libexec/empathy-chat created; pid = 3667
Can't bind address: Address already in use.
Killing process(Gtk-Message: Failed to load module "gtk-vector-screenshot"
(empathy-chat:3619): folks-DEBUG: individual-aggregator.vala:317: Setting primary store IDs to defaults.
(empathy-chat:3619): folks-DEBUG: individual-aggregator.vala:338: Primary store IDs are 'eds' and 'system'.
(empathy-chat:3619): folks-DEBUG: individual-aggregator.vala:350: Constructing IndividualAggregator 0x8540f0
(empathy-chat:3619): folks-DEBUG: Using built-in backends key file '/home/prahal/.local/share/folks/backends.ini' (override with environment variable FOLKS_BACKEND_STORE_KEY_FILE_PATH)
(empathy-chat:3619): Gtk-DEBUG: Connecting to session manager
(empathy-chat:3619): folks-DEBUG: Using built-in backend dir '/opt/gnome/lib64/folks/33/backends' (override with environment variable FOLKS_BACKEND_PATH)
(empathy-chat:3619): folks-DEBUG: backend-store.vala:539: Searching for modules in folder '/opt/gnome/lib64/folks/33/backends' ..
(empathy-chat:3619): folks-DEBUG: backend-store.vala:539: Searching for modules in folder '/opt/gnome/lib64/folks/33/backends/key-file' ..

(empathy-chat:3619): empathy-CRITICAL **: empathy_tp_chat_new: assertion `TP_IS_ACCOUNT (account)' failed

(In reply to comment #2)
> (empathy-chat:3619): empathy-CRITICAL **: empathy_tp_chat_new: assertion
> `TP_IS_ACCOUNT (account)' failed

This is the real bug: either the assertion is valid (in which case some bug is causing it to be false), or it isn't (in which case it should be removed - this is less likely, though).

The segfault for which you have reported a backtrace (Comment #2) is a symptom of that, but I'd prefer to fix the real bug in empathy-chat rather than working around the symptoms.

If you can reproduce this again with G_DEBUG=fatal-warnings in Empathy's environment, that'll produce a different backtrace in which that warning is treated as fatal, so the function at the top of the stack will be g_logv. (fatal_warnings as mentioned in Comment #1 might also work, but fatal-warnings is what the documentation says...)

Sorry it was only the backtrrace I made while debugging. I found how to reproduce in the meantime. Broken ipv6 routing on station (my gateway is from the provider and requires proxyndp , ie flat. Though I found out that since one of the shorewall6 upgrade that I use to set up the proxyndp lines ... the station one was failing because shorewall6 first create the route for the ipv6 then the proxy ndp . But the route for the ipv6 address was already defined and shorewall6 stopped here without setting up the proxyndp for this station.

I set the HAVEROUTE column entry to Yes and all is back on trail (including evolution imapx which was failing due to goa taking too long to reply)

-- 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-glib/issues/144.