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 733891 - empathy and gnome contacts crash when bt phone available
empathy and gnome contacts crash when bt phone available
Status: RESOLVED FIXED
Product: folks
Classification: Platform
Component: BlueZ backend
0.9.x
Other Linux
: Normal major
: Unset
Assigned To: folks-maint
folks-maint
: 733875 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-07-29 00:31 UTC by Mehmet Giritli
Modified: 2014-08-11 14:22 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
bluez: Ensure to yield until OBEX transfers have completed (1.48 KB, patch)
2014-08-08 14:19 UTC, Philip Withnall 		committed Details | Review

Description Mehmet Giritli 2014-07-29 00:31:03 UTC 
Running empathy and gnome-contacts from terminal I see the same error message:

$ empathy
**
bluez:ERROR:bluez-persona-store.c:2645:_folks_backends_blue_z_persona_store_perform_obex_transfer_co:
code should not be reached

It only happens if the computer can connect to my phone over bluetooth. Otherwise everything works perfectly.

Using bluez 5.21 and folks 0.9.7.1.

backtrace:

gdb empathy
GNU gdb (Gentoo 7.6.2 p1) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/bin/empathy...Reading symbols from
/usr/lib64/debug/usr/bin/empathy.debug...done.
done.
(gdb) run
Starting program: /usr/bin/empathy 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffde554700 (LWP 14399)]
[New Thread 0x7fffdd72f700 (LWP 14402)]
[New Thread 0x7fffdcf2e700 (LWP 14403)]
[New Thread 0x7fffcadad700 (LWP 14408)]
[New Thread 0x7fffca5ac700 (LWP 14409)]
[New Thread 0x7fffc9dab700 (LWP 14410)]
[New Thread 0x7fffc95aa700 (LWP 14411)]
[New Thread 0x7fffbb7c8700 (LWP 14425)]
[New Thread 0x7fffbafc7700 (LWP 14426)]
[Thread 0x7fffc95aa700 (LWP 14411) exited]
[Thread 0x7fffcadad700 (LWP 14408) exited]
[New Thread 0x7fffcadad700 (LWP 14460)]
[New Thread 0x7fffc95aa700 (LWP 14461)]
[New Thread 0x7fffba7c6700 (LWP 14463)]
[New Thread 0x7fffb9fc5700 (LWP 14464)]
[New Thread 0x7fffb97c4700 (LWP 14465)]
[New Thread 0x7fffb8fc3700 (LWP 14466)]
[New Thread 0x7fff9ffff700 (LWP 14467)]
[New Thread 0x7fff9f7fe700 (LWP 14469)]
**
bluez:ERROR:bluez-persona-store.c:2645:_folks_backends_blue_z_persona_store_perform_obex_transfer_co:
code should not be reached

Program received signal SIGABRT, Aborted.
0x00007ffff5012955 in raise () from /lib64/libc.so.6

(gdb) bt

+ Trace 233889

  • #0 raise
    from /lib64/libc.so.6
  • #1 abort
    from /lib64/libc.so.6
  • #2 g_assertion_message
    from /usr/lib64/libglib-2.0.so.0
  • #3 g_assertion_message_expr
    from /usr/lib64/libglib-2.0.so.0
  • #4 _folks_backends_blue_z_persona_store_perform_obex_transfer_co
    from /usr/lib64/folks/42/backends/bluez/bluez.so
  • #5 g_simple_async_result_complete
    from /usr/lib64/libgio-2.0.so.0
  • #6 complete_in_idle_cb
    from /usr/lib64/libgio-2.0.so.0
  • #7 g_main_context_dispatch
    from /usr/lib64/libglib-2.0.so.0
  • #8 g_main_context_iterate.isra.23
    from /usr/lib64/libglib-2.0.so.0
  • #9 g_main_context_iteration
    from /usr/lib64/libglib-2.0.so.0
  • #10 g_application_run
    from /usr/lib64/libgio-2.0.so.0
  • #11 main
    at empathy.c line 842 






Comment 1


Philip Withnall





          2014-08-08 14:19:30 UTC
        



Created attachment 282921 [details] [review]
bluez: Ensure to yield until OBEX transfers have completed

It was possible for the code to not yield on an in-progress transfer if
the transfer_status was initially non-null (e.g. ‘queued’). This change
ensures that the transfer is yielded on if the status isn’t ‘complete’
or ‘error’. The yield callback is only invoked once the status has
changed to ‘complete’ or ‘error’, so the code is now guaranteed to not
hit the assert_not_reached() call.






Comment 2


Philip Withnall





          2014-08-08 14:20:03 UTC
        



Attachment 282921 [details] pushed as 5280f33 - bluez: Ensure to yield until OBEX transfers have completed






Comment 3


Philip Withnall





          2014-08-11 14:22:02 UTC
        



*** Bug 733875 has been marked as a duplicate of this bug. ***