GNOME Bugzilla – Bug 593086
empathy crashed with SIGABRT in empathy_tp_chat_acknowledge_message
Last modified: 2009-10-23 13:16:52 UTC
Binary package hint: empathy After several hours of running, empathy will crash, from pasting (usually a) URL to a user. 1) lsb_release -rd Description: Ubuntu 9.04 Release: 9.04 2) empathy: Installed: 2.26.1-1ubuntu1 Candidate: 2.26.1-1ubuntu1 Version table: *** 2.26.1-1ubuntu1 0 500 http://ftp.ussg.iu.edu jaunty/universe Packages 100 /var/lib/dpkg/status 3) empathy sends the message, and continues to work. 4) empathy crashes. Below are the appropriate lines from strace. Also of note: re-opening the chat window shows two (2) lines of the pasted content, however, the recipient receives only one. munmap(0xb53ae000, 4096) = 0 clock_gettime(CLOCK_MONOTONIC, {602498, 28670077}) = 0 gettimeofday({1249324357, 782837}, NULL) = 0 write(2, "**\nERROR:empathy-tp-chat.c:1361:e"..., 99** ERROR:empathy-tp-chat.c:1361:empathy_tp_chat_acknowledge_message: assertion failed: (m != NULL) ) = 99 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(31382, 31382, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- +++ killed by SIGABRT +++ From downstream Ubuntu: https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/408530
I've hit this too. I had a crack at fixing it. It seems that closing a conversation sometimes doesn't actually close the EmpathyChat (like in #532737, but this seems to be somewhat different). As a result, the channel isn't closed, and incoming messages aren't presented to me (but they are logged). Then, when I open a window to that contact again, I see the messages in the scrollback. I try to send a message, and hit an assertion in empathy_tp_chat_acknowledge_message(): m = g_queue_find (priv->pending_messages_queue, message); g_assert (m != NULL); I believe that this is because two different EmpathyChats are listening to the message-received signal on the EmpathyTpChat, and both try to ack the message I send when it's 'received'. (This abstraction is crap.) But I couldn't figure out where the reference leak comes from. I'm suspicious of the tab-dragging code. I wonder if #585089 is a symptom of an underlying problem where Empathy gets confused about which chats are in which window, and loses some of them between the cracks so they aren't closed up when the window is.
https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/436521 has the same crash on GNOME 2.28
There is also a stracktrace on http://launchpadlibrarian.net/32428008/Stacktrace.txt
We should try to fix this in 2.28.x
The ubuntu bug has over 18 duplicates now, seems a frequent issue for users
https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/408530 is the same issue and has 8 duplicates
I'd be interested to know if this bug still happen in 2.28.1. It *could* be a side effect of the last _run_ calls which have been removed in this release.
the ubuntu tracker keeps getting duplicate about 2.28.1 yes
Hm, I can't find a report for Empathy 2.28.1 in lp. I see a lot for 2.28.0.1 though.
the crash are marked duplicates automatically by the retracers but: https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/457621 https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/456850 https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/456592 to have some examples
one user description which could be useful "Empathy crashes when writing to the conversation window. It seems that it crashes if the conversation was opened before, closed and meanwhile the other person wrote something."
one of the ubuntu bug comments has debug log from a session which triggered this crash http://launchpadlibrarian.net/33363102/empathy.log
Some info gathered from the different Ubuntu bugs: - It seems that in all case the sent message causing the crash has been logged twice. - The empathy.log file contains this error (maybe it's not related): (empathy:12846): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (empathy:12846): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
Code path when we send a message: - EmpathyChat: chat_send: call empathy_tp_chat_send (EmpathyTpChat *) - EmpathyTpChat: empathy_tp_chat_send: call the Send D-Bus method - EmpathyTpChat: tp_chat_sent_cb: the "Sent" D-Bus signal is catched. Log ""Message sent" and call tp_chat_build_message - tp_chat_build_message: push the message to priv->messages_queue and call tp_chat_emit_queued_messages - tp_chat_emit_queued_messages: For each queued message: log "Queued message ready", push to pending_messages_queue and fire the EmpathyTpChat::"message-received" signal. This signal is catched in: A) EmpathyChat: chat_message_received_cb - chat_message_received_cb: call chat_message_received() and then empathy_tp_chat_acknowledge_message() - chat_message_received: log "Appending new message from..." and display the message in the text view - EmpathyTpChat: empathy_tp_chat_acknowledge_message: look for the message in pending_messages_queue and assert it's present (leading to our crash). B) EmpathyLogManager: log_manager_chat_received_message_cb - call empathy_log_manager_add_message() - empathy_log_manager_add_message: call empathy_log_store_add_message() - EmpathyLogStore: log_store_empathy_add_message: log "Adding message" and write the file to logs The logs above indicates that B) is executed before A). Each callback seems to be executed twice; there are 2 possibilites: a) There are 2 EmpathyTpChat objects on the same channel. b) EmpathyChat and EmpathyLogManager connected twice the signal on the same object a) seems unlikely as there is only one "Queued message ready" in the log and this debug msg is displayed before firing the the message-received signal. I will continue to investigate how b) could happen.
Actually I think it's more subtile than that. EmpathyChat can't connect twice to the same TpChat: we check that the tp_chat is NULL before seting it and connecting the signals. My current theory is that we have TWO EmpathyChat using the same EmpathyTpChat object. empathy_chat_finalize is never called in the log, so I suspect there is a leak of one EmpathyChat somewhere. It's not easy to track as the refcount management of EmpathyChat is pretty hairy: it's a widget so have a floating reference (it's packed inside the notebook) but is also explicitely reffed/unreffed inside empathy-chat-windows. As Will already suggested, this problem could have the same cause as bug #585089
Adding a ref on the EmpathyChat leads to this crash, so that seems to confirm my theory that the cause of the crash is an EmpathyChat leak.
I'm pretty sure this bug has been introduced by Ubuntu's libindicate patch. See https://bugs.edge.launchpad.net/empathy/+bug/408530/comments/44 for details.