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 747271 - deadlock
deadlock
Status: RESOLVED DUPLICATE of bug 746276
Product: evolution
Classification: Applications
Component: general
3.12.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2015-04-02 21:05 UTC by Brian J. Murrell
Modified: 2015-04-07 09:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Brian J. Murrell 2015-04-02 21:05:44 UTC 
I suspect this is just another symptom of my most recent ticket(s) about the INBOX filtering issue (bug #
746276 -- e_client_cache_get_client_sync() gets stuck), but now evolution is completely deadlocked to the point of not even repainting the UI.

+ Trace 234933

Thread 1 (Thread 0x7fecadf26a40 (LWP 18160))

  • #0 poll
    at ../sysdeps/unix/syscall-template.S line 81
  • #1 g_main_context_iterate.isra
  • #2 g_main_loop_run
  • #3 e_async_closure_wait
    at e-data-server-util.c line 1571
  • #4 e_client_cache_get_client_sync
    at e-client-cache.c line 1141
  • #5 cal_shell_backend_handle_uri_cb
    at e-cal-shell-backend.c line 525
  • #6 e_marshal_BOOLEAN__STRING
    at e-marshal.c line 683
  • #7 g_closure_invoke
  • #8 signal_emit_unlocked_R
  • #9 g_signal_emit_valist
  • #10 g_signal_emit
  • #11 e_shell_handle_uris
    at e-shell.c line 1497
  • #12 shell_action_handle_uris_cb
    at e-shell.c line 217
  • #13 g_closure_invoke
  • #14 signal_emit_unlocked_R
  • #15 g_signal_emit_valist
  • #16 g_signal_emit
  • #17 g_simple_action_activate
  • #18 g_action_activate
  • #19 g_application_exported_actions_activate_action_full
  • #20 org_gtk_Actions_method_call
  • #21 call_in_idle_cb
  • #22 g_main_context_dispatch
  • #23 g_main_context_iterate.isra
  • #24 g_main_loop_run
  • #25 gtk_main
  • #26 main
    at main.c line 685
  • #0 poll
    at ../sysdeps/unix/syscall-template.S line 81
  • #1 g_main_context_iterate.isra
  • #2 g_main_loop_run
  • #3 e_async_closure_wait
    at e-data-server-util.c line 1571
  • #4 e_client_cache_get_client_sync
    at e-client-cache.c line 1141
  • #5 cal_shell_backend_handle_uri_cb
    at e-cal-shell-backend.c line 525
  • #6 e_marshal_BOOLEAN__STRING
    at e-marshal.c line 683
  • #7 g_closure_invoke
  • #8 signal_emit_unlocked_R
  • #9 g_signal_emit_valist
  • #10 g_signal_emit
  • #11 e_shell_handle_uris
    at e-shell.c line 1497
  • #12 shell_action_handle_uris_cb
    at e-shell.c line 217
  • #13 g_closure_invoke
  • #14 signal_emit_unlocked_R
  • #15 g_signal_emit_valist
  • #16 g_signal_emit
  • #17 g_simple_action_activate
  • #18 g_action_activate
  • #19 g_application_exported_actions_activate_action_full
  • #20 org_gtk_Actions_method_call
  • #21 call_in_idle_cb
  • #22 g_main_context_dispatch
  • #23 g_main_context_iterate.isra
  • #24 g_main_loop_run
  • #25 gtk_main
  • #26 main
    at main.c line 685 






Comment 1


Milan Crha





          2015-04-07 09:55:59 UTC
        



Thanks for a bug report. You are right, this is the same issue. The only difference is the place the offending function was called in. This happened when evolution was called with some URI, it can be when opening a calendar from a meeting invitation or any other way. The backtrace doesn't show what URI was used. The difference is that the e_client_cache_get_client_sync() was called in the main thread, which blocked whole application, instead of blocking only a particular dedicated thread.

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