Bug 1221759
| Summary: | [abrt] Crash under book_backend_finalize, g_mutex_clear | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vadim Rutkovsky <vrutkovs> |
| Component: | evolution-data-server | Assignee: | Matthew Barnes <mbarnes> |
| Status: | CLOSED WONTFIX | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | mcrha, tpelka, vbenes, vrutkovs |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://faf-report.itos.redhat.com/reports/bthash/b03ae3c84c39d3086dec36e001d1d97aaff976c0/ | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-03-09 17:35:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Vadim Rutkovsky
2015-05-14 18:39:47 UTC
Thanks for a bug report. The [faf] backtrace looks like: raise abort g_mutex_clear book_backend_finalize g_object_unref data_book_view_dispose g_object_unref e_book_backend_remove_view impl_DataBookView_dispose (In reply to Vadim Rutkovsky from comment #0) > Crashed after stopping gdm service What do you mean with this, please? Can you reproduce it after certain steps? The backtrace suggests that there was a book backend opened in the addressbook factory which had a view running, which was finally closing itself. This close caused a crash, most likely due to reference counting imbalance in the code, causing a use-after-free in the book_backend_finalize(). That means that there might be some applications involved, which had the book opened, in time of the "stopping gdm service" action. There can be involved also the evolution-alarm-notify, through evolution-calendar-factory with the Birthdays & Anniversaries calendar, in case it being marked to show reminders about birthdays and anniversaries. (In reply to Milan Crha from comment #1) > (In reply to Vadim Rutkovsky from comment #0) > > Crashed after stopping gdm service > > What do you mean with this, please? Can you reproduce it after certain steps? Its reproducible during a massive run of EDS unittests, each of them is started sequentially within dogtail-run-headless: <gdm startup> - <unit test runs> - <gdm is stopped>. During one of those cycles the crash happens, I'll check the logs again to see if there is a specific pattern. This isn't likely to happen frequently on real systems, but nevertheless possible - Fedora users have hit this at least 4 times, see https://retrace.fedoraproject.org/faf/reports/507034/ > There can be involved also the evolution-alarm-notify, through > evolution-calendar-factory with the Birthdays & Anniversaries calendar, in > case it being marked to show reminders about birthdays and anniversaries. Right, I'll check those cases, as they seem to be most prone to this crash I tried to reproduce this, just in case, but no luck. I confess I've not much idea what to try. I also run evolution-addressbook-factory under valgrind, but that didn't show anything. My valgrind command was: $ G_SLICE=always-malloc valgrind /usr/libexec/evolution-addressbook-factory -w then wait a bit and when the CPU usage goes back down run your tests. Vadim, any update on this, please? I do not see any crash for 2 months in the FAF report, but that might not mean much. Did you manage to check the logs, please? *** Bug 1367392 has been marked as a duplicate of this bug. *** *** Bug 1349750 has been marked as a duplicate of this bug. *** As I wrote in bug #1349750: I do not have any relevant upstream bug reports, neither fixes I can think of. I see that this happened only once since filled, thus I consider this pretty hard to reproduce, thus unless we have any good reproducer I'm afraid I cannot do anything about it. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. |