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 726733 - Deadlock when multiple threads call g_dbus_connection_get_type()
Deadlock when multiple threads call g_dbus_connection_get_type()
Status: RESOLVED DUPLICATE of bug 674885
Product: glib
Classification: Platform
Component: gdbus
2.44.x
Other Linux
: Normal critical
: ---
Assigned To: David Zeuthen (not reading bugmail)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-03-19 18:06 UTC by Milan Bouchet-Valat
Modified: 2015-05-05 15:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Milan Bouchet-Valat 2014-03-19 18:06:16 UTC
I'm seeing this crash from time to time on Fedora 20, with gnome-contacts-3.10.1-1.fc20, but it apparently occured with 3.6.2 too (see stacktrace).

https://bugzilla.redhat.com/show_bug.cgi?id=881598

warning: core file may not match specified executable file.
[New LWP 19054]
[New LWP 19055]
[New LWP 19056]
warning: "/usr/lib/debug/usr/lib64/libcairo-gobject.so.2.11200.8.debug": separate debug info file has no debug info
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: "/usr/lib/debug/usr/lib64/libicudata.so.49.1.1.debug": separate debug info file has no debug info
Core was generated by `/usr/libexec/gnome-contacts-search-provider'.
Program terminated with signal 5, Trace/breakpoint trap.

Thread 1 (Thread 0x7fea08e12980 (LWP 19054))

  • #0 g_logv
    at gmessages.c line 974
  • #1 g_log
    at gmessages.c line 1003
  • #2 contacts_ensure_eds_accounts
    at contacts-esd-setup.c line 37
  • #3 contacts_search_provider_construct
    at contacts-shell-search-provider.c line 273
  • #4 contacts_search_provider_new
    at contacts-shell-search-provider.c line 292
  • #5 contacts_search_provider_app_real_dbus_register
    at contacts-shell-search-provider.c line 1290
  • #6 g_application_impl_attempt_primary
    at gapplicationimpl-dbus.c line 275
  • #7 g_application_impl_register
    at gapplicationimpl-dbus.c line 407
  • #8 g_application_register
    at gapplication.c line 1306
  • #9 g_application_real_local_command_line
    at gapplication.c line 474
  • #10 g_application_real_local_command_line
    at gapplication.c line 462
  • #11 g_application_run
    at gapplication.c line 1574
  • #12 _vala_main
    at contacts-shell-search-provider.c line 1373
  • #13 __libc_start_main
    at libc-start.c line 225
  • #14 _start

Comment 1 Allan Day 2014-04-07 11:22:16 UTC
Seems like this needs investigation. Milan - it might help if you could say if this is still happening for you.
Comment 2 Michael Catanzaro 2015-04-28 15:25:45 UTC
This was proposed as a F22 blocker since the crash sometimes occurs when the system is started for the first time. Adding Milan to CC since evolution-data-server is implicated. The fatal error is "contacts_ensure_eds_accounts: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources4: Timeout was reached"

  • #0 _g_log_abort
    at gmessages.c line 315
  • #1 g_logv
    at gmessages.c line 1041
  • #2 g_log
    at gmessages.c line 1079
  • #3 contacts_ensure_eds_accounts
    at contacts-esd-setup.c line 117
  • #4 contacts_search_provider_construct
    at contacts-shell-search-provider.c line 526
  • #5 contacts_search_provider_new
    at contacts-shell-search-provider.c line 545
  • #6 contacts_search_provider_app_real_dbus_register
    at contacts-shell-search-provider.c line 2365
  • #7 g_application_impl_attempt_primary
    at gapplicationimpl-dbus.c line 406
  • #8 g_application_impl_register
    at gapplicationimpl-dbus.c line 555
  • #9 g_application_register
    at gapplication.c line 1996
  • #10 g_application_real_local_command_line
    at gapplication.c line 980
  • #11 g_application_run
    at gapplication.c line 2277
  • #12 _vala_main
    at contacts-shell-search-provider.c line 2448
  • #13 main
    at contacts-shell-search-provider.c line 2460

Comment 3 Milan Crha 2015-04-28 19:14:24 UTC
Get backtrace of the evolution-source-registry. If I recall correctly, I see from time to time a deadlock in GLib's GOnce, one thread waiting for something from another thread (dconf relate in my case), which I do not think evolution-data-server can influence by any means.
Comment 4 Erick Perez Castellanos 2015-04-29 04:10:28 UTC
(In reply to Michael Catanzaro from comment #2)
> This was proposed as a F22 blocker since the crash sometimes occurs when the
> system is started for the first time. Adding Milan to CC since
> evolution-data-server is implicated. The fatal error is
> "contacts_ensure_eds_accounts: Error calling StartServiceByName for
> org.gnome.evolution.dataserver.Sources4: Timeout was reached"

Actually, that's not even eds' fault. That's something related with the installation of the services files and the visibility those get from dbus. I've had that error thousands of time on my development environment. Anyhow, does this still happens?
Comment 5 Michael Catanzaro 2015-04-29 14:43:10 UTC
It was reported in 3.16.0, so it's probably still happening.
Comment 6 Erick Perez Castellanos 2015-04-30 04:08:38 UTC
Pushed commit 71d02aa. This one should mitigate the crash, at least. The underlying problem of Contacts not being able to connect to eds should be still there, but that's not our responsibility.

I'll keep the bug open until we hear any updates on this
Comment 7 Michael Catanzaro 2015-05-05 12:45:47 UTC
Moving to glib based on the following comment from Milan in the downstream bug:


"Backtrace of the locked source registry. This is with glib2-2.42.2-1.fc21.x86_64:

Thread 2 (Thread 0x7f9d952e4700 (LWP 2081))

  • #0 __lll_lock_wait
    at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 135
  • #1 __GI___pthread_mutex_lock
    at ../nptl/pthread_mutex_lock.c line 115
  • #2 g_type_add_interface_static
    at gtype.c line 2827
  • #3 g_dbus_connection_get_type
    at gdbusconnection.c line 538
  • #4 get_uninitialized_connection
    at gdbusconnection.c line 6979
  • #5 g_bus_get_sync
    at gdbusconnection.c line 7053
  • #6 dconf_gdbus_get_bus_in_worker
  • #7 dconf_gdbus_method_call
  • #8 g_main_context_dispatch
    at gmain.c line 3111
  • #9 g_main_context_dispatch
    at gmain.c line 3710
  • #10 g_main_context_iterate
    at gmain.c line 3781
  • #11 g_main_context_iteration
    at gmain.c line 3842
  • #12 dconf_gdbus_worker_thread
  • #13 g_thread_proxy
    at gthread.c line 764
  • #14 start_thread
    at pthread_create.c line 310
  • #15 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 109

Thread 1 (Thread 0x7f9d9baa2a00 (LWP 2080))

  • #0 syscall
    at ../sysdeps/unix/sysv/linux/x86_64/syscall.S line 38
  • #1 g_cond_wait
    at gthread-posix.c line 1390
  • #2 g_once_init_enter
    at gthread.c line 649
  • #3 g_dbus_connection_get_type
    at gdbusconnection.c line 538
  • #4 e_dbus_server_class_init
    at e-dbus-server.c line 287
  • #5 e_dbus_server_class_intern_init
    at e-dbus-server.c line 68
  • #6 g_type_class_ref
    at gtype.c line 2217
  • #7 g_type_class_ref
    at gtype.c line 2932
  • #8 g_type_class_ref
    at gtype.c line 2924
  • #9 g_type_class_ref
    at gtype.c line 2924
  • #10 g_object_newv
    at gobject.c line 1869
  • #11 g_object_new
    at gobject.c line 1614
  • #12 e_source_registry_server_new
    at e-source-registry-server.c line 981
  • #13 main
    at evolution-source-registry.c line 200

Both threads are calling
g_dbus_connection_get_type () at gdbusconnection.c:538
each in a different deep level of the call.

I would move this into glib2, because both threads are out of hands for any application. This is the deadlock in the glib2."
Comment 8 Dan Winship 2015-05-05 13:13:52 UTC
The workaround is to do

  g_type_ensure (G_TYPE_DBUS_CONNECTION);

in main().

Maybe we should just do that from _g_io_modules_ensure_loaded() or something until we fix the real bug...

*** This bug has been marked as a duplicate of bug 674885 ***
Comment 9 Milan Crha 2015-05-05 14:59:38 UTC
I pushed the suggested workaround into evolution-data-server sources:

Created commit_fe7affe in eds master (3.17.1+) [1]
Created commit_ebd0142 in eds gnome-3-16 (3.16.2+)

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=fe7affe
Comment 10 Milan Crha 2015-05-05 15:00:05 UTC
(In reply to Milan Crha from comment #9)
> Created commit_fe7affe in eds master (3.17.1+) [1]

Oops, 3.17.2+