After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 656896 - Crash in folks
Crash in folks
Status: RESOLVED DUPLICATE of bug 653599
Product: folks
Classification: Platform
Component: Telepathy backend
git master
Other Linux
: Normal normal
: Unset
Assigned To: folks-maint
folks-maint
Depends on: 656654
Blocks:
 
 
Reported: 2011-08-19 11:35 UTC by Xavier Claessens
Modified: 2011-08-23 07:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Xavier Claessens 2011-08-19 11:35:10 UTC 
Got that crash when starting a chat with a contact:


(empathy:11830): empathy-CRITICAL **: empathy_contact_get_persona: assertion `EMPATHY_IS_CONTACT (contact)' failed

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff689a7a9 in folks_presence_details_get_presence_type () from /usr/lib/libfolks.so.25
(gdb) bt

+ Trace 228144

  • #0 folks_presence_details_get_presence_type
    from /usr/lib/libfolks.so.25
  • #1 presence_cmp_func
    at empathy-contact.c line 1871
  • #2 chat_sort_func
    at empathy-contact.c line 1962
  • #3 g_list_sort_merge
    at /build/buildd/glib2.0-2.29.16/./glib/glist.c line 1055
  • #4 g_list_sort_real
    at /build/buildd/glib2.0-2.29.16/./glib/glist.c line 1101
  • #5 g_list_sort_real
    at /build/buildd/glib2.0-2.29.16/./glib/glist.c line 1101
  • #6 empathy_contact_dup_best_for_action
    at empathy-contact.c line 2053
  • #7 individual_view_row_activated
    at empathy-individual-view.c line 1034
  • #8 individual_view_row_activated
    at empathy-individual-view.c line 1012
  • #9 g_closure_invoke
    at /build/buildd/glib2.0-2.29.16/./gobject/gclosure.c line 773
  • #10 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.29.16/./gobject/gsignal.c line 3309
  • #11 g_signal_emit_valist
    at /build/buildd/glib2.0-2.29.16/./gobject/gsignal.c line 3002
  • #12 g_signal_emit
    at /build/buildd/glib2.0-2.29.16/./gobject/gsignal.c line 3059
  • #13 ??
    from /usr/lib/libgtk-3.so.0
  • #14 ??
    from /usr/lib/libgtk-3.so.0
  • #15 g_closure_invoke
    at /build/buildd/glib2.0-2.29.16/./gobject/gclosure.c line 773
  • #16 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.29.16/./gobject/gsignal.c line 3309
  • #17 g_signal_emit_valist
    at /build/buildd/glib2.0-2.29.16/./gobject/gsignal.c line 3012
  • #18 g_signal_emit
    at /build/buildd/glib2.0-2.29.16/./gobject/gsignal.c line 3059
  • #19 ??
    from /usr/lib/libgtk-3.so.0
  • #20 gtk_propagate_event
    from /usr/lib/libgtk-3.so.0
  • #21 gtk_main_do_event
    from /usr/lib/libgtk-3.so.0
  • #22 ??
    from /usr/lib/libgdk-3.so.0
  • #23 g_main_dispatch
    at /build/buildd/glib2.0-2.29.16/./glib/gmain.c line 2439
  • #24 g_main_context_dispatch
    at /build/buildd/glib2.0-2.29.16/./glib/gmain.c line 3008
  • #25 g_main_context_iterate
    at /build/buildd/glib2.0-2.29.16/./glib/gmain.c line 3086
  • #26 g_main_loop_run
    at /build/buildd/glib2.0-2.29.16/./glib/gmain.c line 3294
  • #27 gtk_main
    from /usr/lib/libgtk-3.so.0
  • #28 g_application_run
    at /build/buildd/glib2.0-2.29.16/./gio/gapplication.c line 1325
  • #29 main
    at empathy.c line 788 






Comment 1


Xavier Claessens





          2011-08-19 11:39:07 UTC
        



FYI, I have folks 0.6.0






Comment 2


Xavier Claessens





          2011-08-19 11:45:02 UTC
        



setting depend on bug #656654 because they are likely the same root cause, but maybe not... Let's verify once that other bug is fixed if this one is fixed as well.






Comment 3


Guillaume Desmottes





          2011-08-22 09:34:16 UTC
        



I'm pretty sure that's a bug of bug #653599. Please re-open if you can
reproduce once this bug has been fixed.

*** This bug has been marked as a duplicate of bug 653599 ***






Comment 4


Travis Reitter





          2011-08-22 19:17:50 UTC
        



As pointed out on IRC, I filed bug #653599 (with a patch) to avoid this problem nearly 2 months ago. I forgot to follow up on it in the scramble to release Folks 0.6.0 (though, honestly, I thought this had been merged a long time ago).

Leading up to 0.6.0, I did basic smoke testing with Empathy, but it was in a branch that contained the fix in bug #653599 and bug #655212 (which was a change that truly depended on the new Folks release to be merged to master).

How can we avoid issues like this bug in the future? I'd like to not need to manually follow up on bugs like bug #653599 (which are immediately-mergeable) when I've already cooked up a patch.






Comment 5


Guillaume Desmottes





          2011-08-23 07:37:45 UTC
        



(In reply to comment #4)
> How can we avoid issues like this bug in the future? I'd like to not need to
> manually follow up on bugs like bug #653599 (which are immediately-mergeable)
> when I've already cooked up a patch.

You should really badger on #empathy until such patch is reviewed (I usually
try to review them right away but forgot sometimes).

Also, I consider you folks guys as proper Empathy reviewer for folks-related
code, so you can also ask to people from your team to review patches if
needed. :)