GNOME Bugzilla – Bug 736006
[abrt] Crash under backend_finalize() during online state change
Last modified: 2015-01-12 13:32:08 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1136778 Version-Release number of selected component: evolution-data-server-3.12.5-3.fc21 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: /usr/libexec/evolution-calendar-factory crash_function: g_mutex_clear executable: /usr/libexec/evolution-calendar-factory kernel: 3.16.1-300.fc21.x86_64 Core was generated by `/usr/libexec/evolution-calendar-factory'. Program terminated with signal SIGABRT, Aborted.
+ Trace 234050
Thread 1 (Thread 0x7fd4ab822840 (LWP 30395))
I hit this immediately after using the Restore from Backup function with "launch Evolution after restore completes" checked. e-d-s crashed when Evolution was launched. The restoration seems to have otherwise worked properly.
3.12.7.1.1.fc21.x86_64 - still seeing this. Seems to happen a lot more often now :/
Abrt mangles the version - this is better: evolution-data-server-3.12.7.1-1.fc21.x86_64
Do you have any pattern, some kind of steps, which would trigger this? Or could you try to watch for one, please? I didn't get this crash myself yet.
I'll keep an eye out. It seems to "just happen" and I haven't been able to observe a pattern yet. I'll run evo from gdb and keep an eye out for this crash to find some reproducible steps.
I do not know how much related, but I've got a similar (forced-by-me) crash when a custom On This Computer calendar was closing. The calendar had set to refresh on the underlying file change. The commit in master is 03a0dfb (3.13.8+) and in stable f089ee9 (3.12.9+), but I would not be surprised if this is not related to your issue at all.
Happen here on a fresh login... So, it seems to be related to sync support... Maybee because i've got owncloud as a dav provider?
The crashing thread in the above backtrace doesn't ensure this being in a CalDAV calendar, but it's possible. I also agree that this can (or mainly?) happens on after/during sync of changes from the remote server (CalDAV speaking). There is a bug #701138 with a similar issue, which can be related. I'm still unable to reproduce this, unfortunately.
I have the same problem with evolution-data-server.x86_64 3.12.8-2.fc21 since I have set up my two ownCloud accounts (syncing only contacts and calendars). Almost every time I log in, the crash occurs after some time. I also think I have seen crashes in evolution-addressbook-factory with a similar backtrace.
For information. This bug never happen in ArchLinux or Debian sid
I'm experiencing the same issue on evolution-data-server-3.12.8-2.fc21.x86_64 I have several Online Accounts: a Jabber, an IRC, a Google account and a kerberos account. The crash occurred at login time.
I think this is addressed with my changes to bug #701138 and to libical within that bug report. I have test builds for Fedora 21 of both, you can get patched packages here: eds - http://koji.fedoraproject.org/koji/taskinfo?taskID=8238292 libical - http://koji.fedoraproject.org/koji/taskinfo?taskID=8237668 Please try with them, who can. Thanks in advance. Also, with respect of libical, it should not show odd times, but just in case, if you notice anything, please let me know (my tests of the libical patch didn't uncover any issue/side-effect, but one never knows).
I too see this on every start of evolution[-data-server processes]. I too have OwnCloud CardDav and CalDav accounts configured. (In reply to comment #12) > eds - http://koji.fedoraproject.org/koji/taskinfo?taskID=8238292 This one is a version regression. It's 3.12.8-2.6 where current F21 has 3.12.9-2.
(In reply to comment #13) > This one is a version regression. It's 3.12.8-2.6 where current F21 has > 3.12.9-2. It didn't a month ago :) The fix for bug #701138 is part of eds 3.12.9, the libical is awaiting review upstream. There is a libical update in updates-testing for Fedora with that change applied. If you still get the crash, then the changes from bug #701138 are unrelated to this particular crash.
(In reply to comment #14) > (In reply to comment #13) > > This one is a version regression. It's 3.12.8-2.6 where current F21 has > > 3.12.9-2. > > It didn't a month ago :) The fix for bug #701138 is part of eds 3.12.9, OK, cool. I have that already then in F21. > the > libical is awaiting review upstream. There is a libical update in > updates-testing for Fedora with that change applied. Just installed 1.0-8.fc21 from updates-testing. We'll see how it goes.
Hrm, according to another downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1178019 this is still an issue with 3.12.9. From the report: Description of problem: Repeated crash starting /usr/libexec/evolution-calendar-factory causing system to lock up with 100% CPU and IO as systemd processes the core dumps. Version-Release number of selected component (if applicable): The problem started occurring with evolution-data-server-3.12.8-1.fc21.x86_64 but did not occur with evolution-data-server-3.12.7.1-1.fc21.x86_64. How reproducible: Always happens Steps to Reproduce: 1. Start with GNOME Desktop (or start Evolution manually in KDE) 2. 3. Actual results: Evolution reports that the "The calendar backend servicing "Personal" has quit unexpectedly." Expected results: Evolution starts up and allows my calendars to be viewed. Additional info: I have a personal calendar stored in Evolution plus 3 external ical calendars from Google and Last.fm ---------------------------------------------------------------------------- I've discovered the underlying cause of the crash. It looks like the GNOME Online Accounts had a set of Google credentials. These had expired. Re-logging in cause the crash in the evolution calendar to stop happening. During the investigation I had removed all of the evolution data files ( as per https://help.gnome.org/users/evolution/3.12/data-storage.html.en) while logged in through a text console. The crash kept happening.
+ Trace 234509
I still cannot reproduce this, with 3.12.9. I tried a Google calendar configured through GOA, then garbled its credentials, thus it could not connect to the server, but even on a network change the calendar factory did not crash. I see there is some reference imbalance, either caused by an incorrect call to an g_object_unref() on an EBackend (ECalBackend), or something called g_object_unref() on an already freed memory, which, by an accident, pointed to the ECalBackend structure. I thought of the later due to the findings in bug #701138, where was happening just that, but it doesn't seem to be the case for you (even the fix works for me just fine). Of course, the accident of unreffing always an ECalBackend is suspicious, but what I can know.
This seems to happen for me on every reboot/login (probably just restart of evolution* processes even).
Backtrace of mine is:
+ Trace 234540
Thread 1 (Thread 0x7f1cda608840 (LWP 2910))
Okay, this is related to a On The Web book on your machine (if the backtrace shows the type properly), while the initial crash comes from the calendar factory. That's a good detail and I think I know what was going on here.
If I understand the last two backtraces properly, then there happened a case when the GSource, which lasts for 5 seconds holds the last reference to the backend, when another network change notification is received, which means that the current GSource is removed first, then a new one is scheduled. The GSource removal also means a deference of the backend, and as it's the last reference, it is also freed. When it comes to clear the mutex the safety checks around it aborts the application due to an attempt to free the mutex when it is locked. Reffing the backend before removing the GSource may fix the crash. This doesn't apply to the first backtrace (comment #0), there might be some other cause for that crash, maybe the one for bug #701138. I'll close this bug rpeort for now, but if there will be any reproducers with evolution-data-server 3.12.11 or later, then I'll reopen it again. This fix missed the 3.12.10 release, unfortunately. I'll provide evolution-data-server 3.12.10-2 for Fedora 21. Created commit 0b34708 in eds master (3.13.10+) [1] Created commit a47f566 in eds evolution-data-server-3-12 (3.12.11+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=0b34708