Description of problem: 1. Installed Workstation from i386 netinst (did not create a user in anaconda). 2. Go through g-i-s 3. Log in 4. See crash notification Version-Release number of selected component: gnome-contacts-3.16.0-1.fc22 Additional info: reporter: libreport-2.5.0 backtrace_rating: 4 cmdline: /usr/libexec/gnome-contacts-search-provider crash_function: _g_log_abort executable: /usr/libexec/gnome-contacts-search-provider global_pid: 2915 kernel: 4.0.0-0.rc5.git4.1.fc22.i686+PAE runlevel: N 5 type: CCpp uid: 1000 var_log_messages: [System Logs]:\n-- Logs begin at Wed 2015-04-08 18:39:09 UTC, end at Wed 2015-04-08 18:44:52 UTC. -- Truncated backtrace: Thread no. 1 (10 frames) #0 _g_log_abort at gmessages.c:315 #3 contacts_ensure_eds_accounts at contacts-esd-setup.c:117 #4 contacts_search_provider_construct at contacts-shell-search-provider.c:526 #5 contacts_search_provider_new at contacts-shell-search-provider.c:545 #6 contacts_search_provider_app_real_dbus_register at contacts-shell-search-provider.c:2365 #7 g_application_impl_attempt_primary at gapplicationimpl-dbus.c:406 #8 g_application_impl_register at gapplicationimpl-dbus.c:555 #9 g_application_register at gapplication.c:1996 #10 g_application_real_local_command_line at gapplication.c:980 #11 g_application_run at gapplication.c:2277
Created attachment 1012361 [details] File: backtrace
Created attachment 1012362 [details] File: cgroup
Created attachment 1012363 [details] File: core_backtrace
Created attachment 1012364 [details] File: dso_list
Created attachment 1012365 [details] File: environ
Created attachment 1012366 [details] File: limits
Created attachment 1012367 [details] File: maps
Created attachment 1012368 [details] File: mountinfo
Created attachment 1012369 [details] File: namespaces
Created attachment 1012370 [details] File: open_fds
Created attachment 1012371 [details] File: proc_pid_status
Proposing as Final Blocker per criterion: There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop.
Discussed at today's blocker review meeting [1]. It was decided to delay the decision, further testing is needed - we're not yet sure whether this is reproducible or a one-off thing, so we'll ask for further testing to find out [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-20/
I couldn't reproduce this just by installing Beta RC3 Workstation netinst today, running through g-i-s creating a user called 'test', skipping online account creation, and logging in. Of course, the packages installed by netinst change from day to day.
I did just see this on a system upgraded from 21 to 22 after I tried launching GNOME Documents.
Probably should not be a blocker if Adam can't reproduce it. I've seen this multiple times before and it should be fixed, but it happens rarely. Milan has requested a backtrace of the evolution-source-registry process ('gdb -p `pidof evolution-source-registry`') right after the crash occurs, but I guess that will be hard to get without a reproducer.
Discussed at the 2015-04-28 blocker review meeting.[1] Voted as RejectedBlocker. Does not seem to occur frequently enough (given the data we have) to be a blocker. The point of the criterion is not to look unprofessional by triggering crashes on all installs; this seems to happen only rarely. [1]: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-28/
I just retested this with TC1 Final, and didn't see it again.
Another user experienced a similar problem: it happens on login to shell. don't really know how to reproduce it. seems to be not persistent reporter: libreport-2.5.1 backtrace_rating: 4 cmdline: /usr/libexec/gnome-contacts-search-provider crash_function: _g_log_abort executable: /usr/libexec/gnome-contacts-search-provider global_pid: 12611 kernel: 4.0.0-1.fc22.x86_64 package: gnome-contacts-3.16.2-1.fc22 reason: gnome-contacts-search-provider killed by SIGTRAP runlevel: N 5 type: CCpp uid: 1000
Backtrace of the locked source registry. This is with glib2-2.42.2-1.fc21.x86_64: Thread 2 (Thread 0x7f9d952e4700 (LWP 2081)): #0 0x000000324b80ef1d in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x000000324b809906 in __GI___pthread_mutex_lock (mutex=0x249ace0) at ../nptl/pthread_mutex_lock.c:115 #2 0x00000032ee631e3c in g_type_add_interface_static (instance_type=instance_type@entry=140314702527152, interface_type=140314702527504, info=info@entry=0x7f9d952e3a30) at gtype.c:2827 #3 0x00000032ef2c8956 in g_dbus_connection_get_type () at gdbusconnection.c:538 #4 0x00000032ef2ca91b in get_uninitialized_connection (bus_type=<optimized out>, cancellable=cancellable@entry=0x0, error=error@entry=0x7f9d952e3ad0) at gdbusconnection.c:6979 #5 0x00000032ef2cfe8b in g_bus_get_sync (bus_type=<optimized out>, cancellable=0x0, error=0x7f9d952e3ad0) at gdbusconnection.c:7053 #6 0x00007f9d952ec038 in dconf_gdbus_get_bus_in_worker () at /usr/lib64/gio/modules/libdconfsettings.so #7 0x00007f9d952ec11a in dconf_gdbus_method_call () at /usr/lib64/gio/modules/libdconfsettings.so #8 0x00000032ee2497fb in g_main_context_dispatch (context=0x24ea890) at gmain.c:3111 #9 0x00000032ee2497fb in g_main_context_dispatch (context=context@entry=0x24ea890) at gmain.c:3710 #10 0x00000032ee249b98 in g_main_context_iterate (context=context@entry=0x24ea890, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781 #11 0x00000032ee249c4c in g_main_context_iteration (context=0x24ea890, may_block=1) at gmain.c:3842 #12 0x00007f9d952ec24d in dconf_gdbus_worker_thread () at /usr/lib64/gio/modules/libdconfsettings.so #13 0x00000032ee2703d5 in g_thread_proxy (data=0x24b5050) at gthread.c:764 #14 0x000000324b80752a in start_thread (arg=0x7f9d952e4700) at pthread_create.c:310 #15 0x000000324ad0022d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7f9d9baa2a00 (LWP 2080)): #0 0x000000324acfa939 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x00000032ee28e2fc in g_cond_wait (cond=cond@entry=0x32ee538560 <g_once_cond>, mutex=mutex@entry=0x32ee538570 <g_once_mutex>) at gthread-posix.c:1390 #2 0x00000032ee27052b in g_once_init_enter (location=location@entry=0x32ef5765a8) at gthread.c:649 #3 0x00000032ef2c88b4 in g_dbus_connection_get_type () at gdbusconnection.c:538 #4 0x00007f9d9c3547b4 in e_dbus_server_class_init (class=0x24ec290) at e-dbus-server.c:287 #5 0x00007f9d9c3540e3 in e_dbus_server_class_intern_init (klass=0x24ec290) at e-dbus-server.c:68 #6 0x00000032ee62ec39 in g_type_class_ref (pclass=0x249ad10, node=0x24ebe90) at gtype.c:2217 #7 0x00000032ee62ec39 in g_type_class_ref (type=<optimized out>) at gtype.c:2932 #8 0x00000032ee62e934 in g_type_class_ref (type=<optimized out>) at gtype.c:2924 #9 0x00000032ee62e934 in g_type_class_ref (type=type@entry=38715728) at gtype.c:2924 #10 0x00000032ee616c1a in g_object_newv (object_type=object_type@entry=38715728, n_parameters=n_parameters@entry=0, parameters=parameters@entry=0x0) at gobject.c:1869 #11 0x00000032ee6173a4 in g_object_new (object_type=38715728, first_property_name=0x0) at gobject.c:1614 #12 0x00007f9d9c35c5b6 in e_source_registry_server_new () at e-source-registry-server.c:981 #13 0x0000000000404ca8 in main (argc=1, argv=0x7fff9b0fb218) at evolution-source-registry.c: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.
I just committed a workaround for 3.17.2+ [1] and 3.16.2+ in evolution-data-server. The 3.16.2 will be released the next Monday, thus I'm not updating the current 3.16.1, because it might not get into live soon enough anyway. [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=fe7affe
*** Bug 881598 has been marked as a duplicate of this bug. ***
*** Bug 1132717 has been marked as a duplicate of this bug. ***