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 683548 - Hang on start of Evolution
Hang on start of Evolution
Status: RESOLVED NOTGNOME
Product: libsoup
Classification: Core
Component: Misc
2.38.x
Other Linux
: Normal critical
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2012-09-07 05:46 UTC by Milan Crha
Modified: 2012-09-10 08:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Milan Crha 2012-09-07 05:46:27 UTC 
I just got this hang on start of evolution. The main thread is blocked in libsoup. See the other threads too. This is with:
   libsoup-2.38.1-1.fc17.x86_64
   glib2-2.32.4-1.fc17.x86_64
   gtk3-3.4.4-1.fc17.x86_64
   webkitgtk3-1.8.1-2.fc17.x86_64

+ Trace 230816

Thread 6 (Thread 0x7ff008906700 (LWP 1783))

  • #0 poll
    from /lib64/libc.so.6
  • #1 g_main_context_poll
    at gmain.c line 3440
  • #2 g_main_context_iterate
    at gmain.c line 3141
  • #3 g_main_loop_run
    at gmain.c line 3340
  • #4 e_async_closure_wait
    at e-data-server-util.c line 1341
  • #5 e_ews_connection_sync_folder_hierarchy_sync
    at e-ews-connection.c line 3390
  • #6 ews_authenticate_sync
    at camel-ews-store.c line 552
  • #7 camel_service_authenticate_sync
    at camel-service.c line 1970
  • #8 mail_authenticator_try_password_sync
    at e-mail-authenticator.c line 165
  • #9 e_source_authenticator_try_password_sync
    at e-source-authenticator.c line 418
  • #10 source_registry_authenticate_authenticate_cb
    at e-source-registry.c line 1482
  • #11 ffi_call_unix64
    from /lib64/libffi.so.5
  • #12 ffi_call
    from /lib64/libffi.so.5
  • #13 g_cclosure_marshal_generic
    at gclosure.c line 1454
  • #14 g_closure_invoke
    at gclosure.c line 777
  • #15 signal_emit_unlocked_R
    at gsignal.c line 3551
  • #16 g_signal_emitv
    at gsignal.c line 3041
  • #17 e_dbus_authenticator_proxy_g_signal
    at e-dbus-authenticator.c line 1049
  • #18 ffi_call_unix64
    from /lib64/libffi.so.5
  • #19 ffi_call
    from /lib64/libffi.so.5
  • #20 g_cclosure_marshal_generic
    at gclosure.c line 1454
  • #21 g_closure_invoke
    at gclosure.c line 777
  • #22 signal_emit_unlocked_R
    at gsignal.c line 3589
  • #23 g_signal_emit_valist
    at gsignal.c line 3300
  • #24 g_signal_emit
    at gsignal.c line 3356
  • #25 on_signal_received
    at gdbusproxy.c line 927
  • #26 emit_signal_instance_in_idle_cb
    at gdbusconnection.c line 3665
  • #27 g_main_dispatch
    at gmain.c line 2539
  • #28 g_main_context_dispatch
    at gmain.c line 3075
  • #29 g_main_context_iterate
    at gmain.c line 3146
  • #30 g_main_loop_run
    at gmain.c line 3340
  • #31 e_source_registry_authenticate_sync
    at e-source-registry.c line 1685
  • #32 mail_session_authenticate_sync
    at e-mail-session.c line 1540
  • #33 camel_session_authenticate_sync
    at camel-session.c line 1769
  • #34 ews_connect_sync
    at camel-ews-store.c line 402
  • #35 service_connect_thread
    at camel-service.c line 763
  • #36 run_in_thread
    at gsimpleasyncresult.c line 861
  • #37 io_job_thread
    at gioscheduler.c line 177
  • #38 g_thread_pool_thread_proxy
    at gthreadpool.c line 309
  • #39 g_thread_proxy
    at gthread.c line 801
  • #40 start_thread
    from /lib64/libpthread.so.0
  • #41 clone
    from /lib64/libc.so.6 






Comment 1


Matthew Barnes





          2012-09-07 11:25:02 UTC
        



This might actually be related to bug 674885, which I found out about yesterday and have seen manifest in a number of different ways.






Comment 2


Dan Winship





          2012-09-07 12:18:59 UTC
        



this is slightly different from 674885, in that each of the two class_init functions is creating an instance of another object, which someone somewhere claimed is illegal. Though the suggested fix in 674885 (getting rid of class_init_rec_mutex) would probably fix this anyway...






Comment 3


Dan Winship





          2012-09-07 14:30:50 UTC
        



(In reply to comment #2)
> this is slightly different from 674885, in that each of the two class_init
> functions is creating an instance of another object

Actually, that's not true; only the webkit thread is. Filed https://bugs.webkit.org/show_bug.cgi?id=96105.

For now (or if they can't manage to fix webkitInit() before 3.6) your best bet is probably to g_type_ensure(WEBKIT_TYPE_WEBVIEW) before any other threads are started.






Comment 4


Matthew Barnes





          2012-09-07 14:38:36 UTC
        



Note, Evolution 3.6 is only requiring GLib 2.32.  g_type_ensure() is new in GLib 2.33, but you can achieve the same effect with something like:

  g_type_class_unref (g_type_class_ref (WEBKIT_TYPE_WEBVIEW))






Comment 5


Milan Crha





          2012-09-10 08:44:50 UTC
        



Because I have quite bad experience with the Webkit upstream, then I made a workaround in Evolution, commit a276c7c (3.5.92+). I also mimic g_type_ensure(), as it seemed better to me.