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 735308 - [abrt] gnome-shell: calendar_sources_init(): gnome-shell-calendar-server killed by SIGTRAP
[abrt] gnome-shell: calendar_sources_init(): gnome-shell-calendar-server kill...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: calendar
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2014-08-24 05:24 UTC by Ankur Sinha (FranciscoD)
Modified: 2014-12-15 01:18 UTC
See Also:
GNOME target: ---
GNOME version: 3.13/3.14


Attachments
calendar-server: activate evolution-source-registry manually at startup (3.54 KB, patch)
2014-12-11 00:47 UTC, Giovanni Campagna
committed Details | Review
Calendar: ignore timeouts starting the calendar-server (2.68 KB, patch)
2014-12-11 00:47 UTC, Giovanni Campagna
committed Details | Review

Description Ankur Sinha (FranciscoD) 2014-08-24 05:24:48 UTC
Downstream abrt bug: https://bugzilla.redhat.com/show_bug.cgi?id=1123674

More info available there.

Version-Release number of selected component:
gnome-shell-3.13.4-1.fc21

Additional info:
reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/libexec/gnome-shell-calendar-server
crash_function: calendar_sources_init
executable:     /usr/libexec/gnome-shell-calendar-server
kernel:         3.16.0-0.rc6.git2.1.fc21.x86_64
runlevel:       unknown
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (9 frames)
 #2 calendar_sources_init
 #3 g_type_create_instance at /lib64/libgobject-2.0.so.0
 #4 g_object_new_internal at /lib64/libgobject-2.0.so.0
 #7 calendar_sources_get
 #8 on_bus_acquired
 #9 connection_get_cb at /lib64/libgio-2.0.so.0
 #10 g_simple_async_result_complete at /lib64/libgio-2.0.so.0
 #11 complete_in_idle_cb at /lib64/libgio-2.0.so.0
 #13 g_main_context_iterate.isra at /lib64/libglib-2.0.so.0
Comment 1 drago01 2014-08-24 08:44:55 UTC
From the downstream bug:

----
[System Logs]:
Jul 27 17:50:01 localhost.localdomain abrt-hook-ccpp[2025]: Saved core dump of pid 2017 (/usr/libexec/gnome-shell-calendar-server) to /var/tmp/abrt/ccpp-2014-07-27-17:50:01-2017 (36614144 bytes)
[User Logs]:
Jul 27 17:49:48 localhost.localdomain org.gnome.Shell.CalendarServer[657]: gnome-shell-calendar-server[901]: Lost (or failed to acquire) the name org.gnome.Shell.CalendarServer - exiting
Jul 27 17:50:01 localhost.localdomain org.gnome.Shell.CalendarServer[1878]: (gnome-shell-calendar-server:2017): ShellCalendarServer-ERROR **: calendar_sources_init: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources3: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program org.gnome.evolution.dataserver.Sources3: Success
-----

Do you have evolution-data-server installed?
Comment 2 Ankur Sinha (FranciscoD) 2014-08-24 08:54:16 UTC
Yes. I just installed the system from alpha-TC3:

[asinha@localhost  ~]$ rpm -qa \*evolution\*
evolution-data-server-debuginfo-3.12.5-2.fc21.x86_64
evolution-data-server-3.12.5-2.fc21.x86_64
evolution-ews-3.12.5-2.fc21.x86_64
evolution-help-3.12.5-2.fc21.noarch
evolution-3.12.5-2.fc21.x86_64
[asinha@localhost  ~]$
Comment 3 Ankur Sinha (FranciscoD) 2014-10-06 13:58:00 UTC
Still seeing this:

gnome-shell-3.14.0-2.fc21.x86_64

After this, when the shell comes up, the calendars aren't shown in the top panel - neither are the "open calendar" option. If I restart the shell, they show up. Probably something to do with e-d-s.
Comment 4 Ankur Sinha (FranciscoD) 2014-10-07 09:04:55 UTC
Seems like it happens on each login. Not sure how to collect more info. Any hints?
Comment 5 Giovanni Campagna 2014-12-11 00:05:32 UTC
After some investigation, it seems to be caused by hitting the 25 seconds timeout on starting evolution-source-registry.

Relevant logs:
Dec 10 10:51:14 giovanni-laptop org.gnome.Shell.CalendarServer[1439]: (gnome-shell-calendar-server:1568): ShellCalendarServer-ERROR **: calendar_sources_init: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources3: Timeout was reached
Dec 10 10:51:49 giovanni-laptop gnome-session[1431]: Gjs-Message: JS LOG: Error loading calendars: Error calling StartServiceByName for org.gnome.Shell.CalendarServer: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process org.gnome.Shell.CalendarServer received signal 5
Dec 10 10:51:21 giovanni-laptop gnome-session[1431]: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources3: Timeout was reached
Dec 10 10:52:01 giovanni-laptop org.gnome.evolution.dataserver.Sources3[1439]: Bus name 'org.gnome.evolution.dataserver.Sources3' acquired.

evolution-source-registry is running fine, but you can see it takes 47 seconds to start (I don't know who is trying to start e-s-r at 10:51:21, maybe some other app or service?)

Now, ideally e-s-r would not take this long before acquiring the bus name. Looking at the code, it seems that before acquiring the bus name, it tries to migrate the old (pre 3.12? 3.10?) configuration, which can be disabled, but it also tries to synchronously load all sources from the disk.
A simple test on my system shows that it takes 12 seconds (10 if I disable migration) to load, with no other concurrent IO but with cold caches.
It is clear that hitting 25 is possible, in a condition such as login where there is a lot of other concurrent IO happening.

OTOH, we cannot increase the timeout: g_dbus_proxy_new (eventually called by e_source_registry_new()) hardcodes using the default timeout for its StartServiceByName call, and g_dbus_connection_call() hardcodes 25 seconds as the default.
We could change the timeout to be higher for all gdbus programs, or for all g_dbus_proxy_new() calls, on the grounds that starting a service can reasonably require more than 25 seconds if the service has to load itself, its configuration and its data. I'm not sure it's a good idea in general.

OTOH, a simple workaround is to StartServiceByName manually before using the eds library call, with a higher timeout.
Comment 6 Giovanni Campagna 2014-12-11 00:47:09 UTC
Created attachment 292502 [details] [review]
calendar-server: activate evolution-source-registry manually at startup

g_dbus_proxy_new() (and library calls that wrap it) has an hardcoded
timeout of 25 seconds, which is insufficient for starting up e-s-r
in certain setups. Avoid a timeout error by starting the service
manually with a longer timeout before hand.
Also demote the error to a warning + exit failure instead of
a crash, to avoid triggering abrt reports.
Comment 7 Giovanni Campagna 2014-12-11 00:47:13 UTC
Created attachment 292503 [details] [review]
Calendar: ignore timeouts starting the calendar-server

In certain cases the timeout for starting the calendar helper can
be reached but the calendar helper still loads fine. If so, just
ignore the timeout and wait until we get a notification from
dbus of the successful start.
Comment 8 drago01 2014-12-14 22:46:57 UTC
Review of attachment 292502 [details] [review]:

While this is a hack its better then what we have now.
Comment 9 drago01 2014-12-14 22:47:46 UTC
Review of attachment 292503 [details] [review]:

OK.
Comment 10 Giovanni Campagna 2014-12-15 01:18:47 UTC
Pushed to master and gnome-3-14

Attachment 292502 [details] pushed as b21f5c5 - calendar-server: activate evolution-source-registry manually at startup
Attachment 292503 [details] pushed as 0592ade - Calendar: ignore timeouts starting the calendar-server