Bug 1464136 - [abrt] evolution-data-server: g_type_check_instance_is_fundamentally_a(): evolution-calendar-factory-subprocess killed by signal 11
[abrt] evolution-data-server: g_type_check_instance_is_fundamentally_a(): evo...
Status: NEW
Product: Fedora
Classification: Fedora
Component: evolution-data-server (Show other bugs)
26
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Milan Crha
Fedora Extras Quality Assurance
https://retrace.fedoraproject.org/faf...
abrt_hash:f8782cc694e673e2a4824ef582c...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-22 09:44 EDT by Matthew Saltzman
Modified: 2017-08-03 17:34 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (123.29 KB, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: cgroup (365 bytes, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: core_backtrace (104.76 KB, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: cpuinfo (1.39 KB, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: dso_list (18.25 KB, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: environ (1.29 KB, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: exploitable (82 bytes, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: limits (1.29 KB, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: maps (88.50 KB, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: open_fds (1.36 KB, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: proc_pid_status (1.27 KB, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details
File: var_log_messages (28 bytes, text/plain)
2017-06-22 09:44 EDT, Matthew Saltzman
no flags Details

  None (edit)
Description Matthew Saltzman 2017-06-22 09:44:36 EDT
Version-Release number of selected component:
evolution-data-server-3.24.2-2.fc26

Additional info:
reporter:       libreport-2.9.1
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-calendar-factory-subprocess --factory ews --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.Calendarx1999x5 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/Calendar/1999/5
crash_function: g_type_check_instance_is_fundamentally_a
executable:     /usr/libexec/evolution-calendar-factory-subprocess
journald_cursor: s=93e45a7acd3e44f783cf884369ff9dc5;i=38d1eb;b=d583673b9606462fa96e0041e3327f9b;m=315ea3af0;t=5527066ff39a8;x=a8058aaf6716d638
kernel:         4.11.5-300.fc26.x86_64
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 g_type_check_instance_is_fundamentally_a at gtype.c:4025
 #2 cal_backend_sexp_finalize at /usr/src/debug/evolution-data-server-3.24.2/src/calendar/libedata-cal/e-cal-backend-sexp.c:1103
 #4 data_cal_view_dispose at /usr/src/debug/evolution-data-server-3.24.2/src/calendar/libedata-cal/e-data-cal-view.c:434
 #6 e_cal_backend_remove_view at /usr/src/debug/evolution-data-server-3.24.2/src/calendar/libedata-cal/e-cal-backend.c:1441
 #7 impl_DataCalView_dispose at /usr/src/debug/evolution-data-server-3.24.2/src/calendar/libedata-cal/e-data-cal-view.c:265
 #8 ffi_call_unix64 at ../src/x86/unix64.S:76
 #9 ffi_call at ../src/x86/ffi64.c:525
 #10 g_cclosure_marshal_generic at gclosure.c:1490
 #15 e_gdbus_stub_handle_method_call at /usr/src/debug/evolution-data-server-3.24.2/src/libedataserver/e-gdbus-templates.c:677
 #16 call_in_idle_cb at gdbusconnection.c:4850
Comment 1 Matthew Saltzman 2017-06-22 09:44:41 EDT
Created attachment 1290714 [details]
File: backtrace
Comment 2 Matthew Saltzman 2017-06-22 09:44:42 EDT
Created attachment 1290715 [details]
File: cgroup
Comment 3 Matthew Saltzman 2017-06-22 09:44:44 EDT
Created attachment 1290716 [details]
File: core_backtrace
Comment 4 Matthew Saltzman 2017-06-22 09:44:45 EDT
Created attachment 1290717 [details]
File: cpuinfo
Comment 5 Matthew Saltzman 2017-06-22 09:44:46 EDT
Created attachment 1290718 [details]
File: dso_list
Comment 6 Matthew Saltzman 2017-06-22 09:44:48 EDT
Created attachment 1290719 [details]
File: environ
Comment 7 Matthew Saltzman 2017-06-22 09:44:49 EDT
Created attachment 1290720 [details]
File: exploitable
Comment 8 Matthew Saltzman 2017-06-22 09:44:50 EDT
Created attachment 1290721 [details]
File: limits
Comment 9 Matthew Saltzman 2017-06-22 09:44:52 EDT
Created attachment 1290722 [details]
File: maps
Comment 10 Matthew Saltzman 2017-06-22 09:44:53 EDT
Created attachment 1290723 [details]
File: open_fds
Comment 11 Matthew Saltzman 2017-06-22 09:44:54 EDT
Created attachment 1290724 [details]
File: proc_pid_status
Comment 12 Matthew Saltzman 2017-06-22 09:44:55 EDT
Created attachment 1290725 [details]
File: var_log_messages
Comment 13 Milan Crha 2017-06-23 03:18:41 EDT
Thanks for a bug report. I see from the backtrace that this crashed when one of your EWS calendars had been notified about no longer active view. It can happen from anywhere, including GNOME Shell's calendar server, like when moving between days to show (in any calendar application which uses evolution-data-server, not only in GNOME Shell). The pointer address it crashed with is used in another thread as well, by libsoup.  It can be that there's some ref/unref imbalance somewhere in the code, either directly in evolution-ews, or in evolution-data-server or even in libsoup. It's hard to tell from the backtrace. I'll check the usage of this object in the code, but if it broke due to some other code writing to already freed memory, thus effectively overwriting memory it didn't belong to it any more, then it'll be quite hard to find it (because it could be just a coincidence that it touched this object).
Comment 14 Milan Crha 2017-06-23 04:00:20 EDT
I checked the code, but I didn't find anything obvious. The object in question is a private member, and the places where it is exposed look fine (by code reading). Unless the impl_DataCalView_dispose() being called twice for one view I'd say there is not much chance that this could happen in properly running environment (with that I mean that the code looks correct, thus it's possible that the problem is about some use-after-free or similar issue, something touching code it should not).

Having a reproducer would be a good start, but as such issues are pretty hard to spot (and they tend to strike on different place each time) I'm afraid we have bad luck.

Note You need to log in before you can comment on or make changes to this bug.