Version-Release number of selected component: evolution-data-server-3.24.2-1.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.Calendarx2125x5 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/Calendar/2125/5 crash_function: g_type_check_instance_is_fundamentally_a executable: /usr/libexec/evolution-calendar-factory-subprocess journald_cursor: s=9fe1a0268af84cfe84c2126c337af0cb;i=267da;b=724198283a014498bd329fe892f58a21;m=1c1d343;t=54fa602b8bd5a;x=1fee2d34c2c8da5e kernel: 4.11.0-2.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:4023 #1 g_object_ref at gobject.c:3051 #2 soup_socket_set_property at soup-socket.c:345 #3 object_set_property at gobject.c:1423 #4 g_object_new_internal at gobject.c:1837 #5 g_object_new_valist at gobject.c:2042 #6 soup_socket_new at soup-socket.c:824 #7 soup_connection_connect_async at soup-connection.c:397 #8 get_connection at soup-session.c:1937 #9 soup_session_process_queue_item at soup-session.c:1964 Potential duplicate: bug 1361015
Created attachment 1284665 [details] File: backtrace
Created attachment 1284666 [details] File: cgroup
Created attachment 1284667 [details] File: core_backtrace
Created attachment 1284668 [details] File: cpuinfo
Created attachment 1284669 [details] File: dso_list
Created attachment 1284670 [details] File: environ
Created attachment 1284671 [details] File: exploitable
Created attachment 1284672 [details] File: limits
Created attachment 1284673 [details] File: maps
Created attachment 1284674 [details] File: open_fds
Created attachment 1284675 [details] File: proc_pid_status
Created attachment 1284676 [details] File: var_log_messages
Thanks for a bug report. I think this is a similar issue as yours bug #1446226, only this time in the calendar factory, not in the address book factory. I'm wondering how to debug this further, as you seem to be able to reproduce this often, while I do not face it myself here, neither I see any recent reports from other users about the same thing (which might not necessarily mean much, as used can have set up to not report issues to bugzilla by default; on the other hand, the FAF URL (above) shows only one occurrence for the past month).
Hi! Unfortunately I have no idea why this is happening :(. There must be something very specific to my case, maybe due to something weird with the exchange server that I use for work. If you have any idea how I can give you more information to help you investigate, please do not hesitate. And if this bug does not get fixed, it's completely fine, as from my perspective this is simply an ABRT notification popping up once in a while. No big deal.
Your environment is great, because it can reproduce the issue. Where the actual problem is is the question, it can be in any library, from evolution-ews to libsoup (I vaguely recall some libsoup issues not being fixed, but I do not have any exact pointers and my memory is poor) or even lower in the stack. I usually try to catch such memory issues with valgrind. The downside of valgrind is that it significantly slows down the responses, due to all the memory checking. It also causes high CPU usage for the same reason. The commands would be to run the background processes from a terminals: a) open one terminal window and run there: $ G_SLICE=always-malloc valgrind --num-callers=30 --trace-children=yes \ /usr/libexec/evolution-calendar-factory -w &>~/ecf.log b) open another terminal window and run there: $ G_SLICE=always-malloc valgrind --num-callers=30 --trace-children=yes \ /usr/libexec/evolution-addressbook-factory -w &>~/ecf.log c) wait a bit, until the both processes settle their activity, which will also mean that they are registered on the D-Bus and they replaced those previously runnign background processes d) kill running evolution-alarm-notify process, either with: $ pkill evolution-alarm-notify or get its process ID: $ ps ax | grep evolution-al and then stop it: $ kill -TERM PID e) run evolution and use it "as before" (quotes due to significantly slower response from both calendars and address books) Valgrind is able to avoid certain crashes and it notifies about them only. Thus even if you'd not receive any crash, the logs can still contain valuable information. If you can, please, try to use it for a day or so, but if it'll slow your work too much, then just stop the processes from a) and b) (by using Ctrl+C in the respective terminal window) and work as before. The thing is that due to the memory checking the valgrind can avoid the issue only for the slowness, in case the issue depends on "proper timing". There are other possibilities, like using address sanitizer, but it requires special build of the packages, which is not practical.
(In reply to Milan Crha from comment #15) > /usr/libexec/evolution-calendar-factory -w &>~/ecf.log > ... > /usr/libexec/evolution-addressbook-factory -w &>~/ecf.log Oops, the calendar factory should use ecf.log, while the address book factory eaf.log, definitely not the same file. Copy&paste error on my side, I'm sorry about that.
Similar problem has been detected: Trying to add recipients from address book. reporter: libreport-2.9.1 backtrace_rating: 4 cmdline: /usr/libexec/evolution-addressbook-factory-subprocess --factory ews --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx2938x15 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/2938/15 crash_function: g_type_check_instance_is_fundamentally_a executable: /usr/libexec/evolution-addressbook-factory-subprocess journald_cursor: s=fa3b7875031e412ab6834e77cb9d413b;i=8f06;b=3e19ab9711d54a55ad15bdf23a80ca8e;m=1e5f341e5;t=55533b85e5543;x=eb5a5292664e2e18 kernel: 4.11.11-300.fc26.x86_64 package: evolution-data-server-3.24.4-1.fc26 reason: evolution-addressbook-factory-subprocess killed by signal 11 rootdir: / runlevel: N 5 type: CCpp uid: 1000
I'm moving this to libsoup, I saw a similar issue also with a CalDAV calendar backend, thus it's not evolution-ews specific, even it strikes there the most. I'm not able to reproduce it currently (I saw it few months back, but even then it was more like a bad luck than consistent reproducer).
*** Bug 1488588 has been marked as a duplicate of this bug. ***
*** Bug 1491196 has been marked as a duplicate of this bug. ***
*** Bug 1493742 has been marked as a duplicate of this bug. ***
*** Bug 1498981 has been marked as a duplicate of this bug. ***
*** Bug 1505700 has been marked as a duplicate of this bug. ***
*** Bug 1484940 has been marked as a duplicate of this bug. ***
*** Bug 1459045 has been marked as a duplicate of this bug. ***
While this happens most often in connection with evolution-data-server background processes, involving evolution-ews backend, the bug #1459045 is from gnome-software package and bug #1484940 from corebird package, which sort of confirms that the issue is somewhere in libsoup (eventually in other common part between these packages).
An upstream bug report [1] contains a proposed fix. I'll probably create an update in Fedora, once the upstream fix is accepted/discussed. [1] https://bugzilla.gnome.org/show_bug.cgi?id=762138
*** Bug 1513915 has been marked as a duplicate of this bug. ***
libsoup-2.60.2-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-fc4ed61dfc
libsoup-2.60.2-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-fc4ed61dfc
libsoup-2.60.2-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1520114 has been marked as a duplicate of this bug. ***
*** Bug 1552888 has been marked as a duplicate of this bug. ***
*** Bug 1436680 has been marked as a duplicate of this bug. ***
*** Bug 1472779 has been marked as a duplicate of this bug. ***
*** Bug 1459168 has been marked as a duplicate of this bug. ***