Description of problem: Start Evoluton mail client, crash. Version-Release number of selected component: evolution-3.30.1-1.fc29 Additional info: reporter: libreport-2.9.5 backtrace_rating: 4 cmdline: evolution crash_function: g_source_set_ready_time executable: /usr/bin/evolution journald_cursor: s=129438ef57ab4b65a57039047feb4005;i=5505c;b=9e472a6e2d684a7db9c9108da025b108;m=8fa5ea378;t=5771b11fbab3a;x=d642a9ae31f0d50b kernel: 4.18.10-300.fc29.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 g_source_set_ready_time at gmain.c:1847 #1 WTF::ThreadSafeRefCounted<IPC::Connection, (WTF::DestructionThread)1>::deref at /usr/include/c++/8/bits/unique_ptr.h:270 #2 WTF::Ref<IPC::Connection, WTF::DumbPtrTraits<IPC::Connection> >::~Ref at /usr/src/debug/webkit2gtk3-2.22.2-1.fc29.x86_64/x86_64-redhat-linux-gnu/DerivedSources/ForwardingHeaders/wtf/Ref.h:61 #3 IPC::Connection::<lambda()>::~<lambda> at /usr/src/debug/webkit2gtk3-2.22.2-1.fc29.x86_64/Source/WebKit/Platform/IPC/Connection.cpp:373 #4 WTF::Function<void()>::CallableWrapper<IPC::Connection::invalidate()::<lambda()> >::~CallableWrapper at /usr/src/debug/webkit2gtk3-2.22.2-1.fc29.x86_64/x86_64-redhat-linux-gnu/DerivedSources/ForwardingHeaders/wtf/Function.h:91 #5 WTF::Function<void()>::CallableWrapper<IPC::Connection::invalidate()::<lambda()> >::~CallableWrapper(void) at /usr/src/debug/webkit2gtk3-2.22.2-1.fc29.x86_64/x86_64-redhat-linux-gnu/DerivedSources/ForwardingHeaders/wtf/Function.h:91 #6 std::default_delete<WTF::Function<void ()>::CallableWrapperBase>::operator()(WTF::Function<void ()>::CallableWrapperBase*) const at /usr/include/c++/8/bits/unique_ptr.h:347 #7 std::unique_ptr<WTF::Function<void ()>::CallableWrapperBase, std::default_delete<WTF::Function<void ()>::CallableWrapperBase> >::~unique_ptr() at /usr/include/c++/8/bits/unique_ptr.h:274 #8 WTF::Function<void ()>::~Function() at /usr/src/debug/webkit2gtk3-2.22.2-1.fc29.x86_64/Source/WTF/wtf/Function.h:36 #9 WTF::WorkQueue::<lambda()>::~<lambda> at /usr/src/debug/webkit2gtk3-2.22.2-1.fc29.x86_64/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:62
Created attachment 1488666 [details] File: backtrace
Created attachment 1488667 [details] File: cgroup
Created attachment 1488668 [details] File: core_backtrace
Created attachment 1488669 [details] File: cpuinfo
Created attachment 1488670 [details] File: dso_list
Created attachment 1488671 [details] File: environ
Created attachment 1488672 [details] File: limits
Created attachment 1488673 [details] File: maps
Created attachment 1488674 [details] File: mountinfo
Created attachment 1488675 [details] File: open_fds
Created attachment 1488676 [details] File: proc_pid_status
Created attachment 1488677 [details] File: exploitable
Thanks for a bug report. It seems to me that evolution is exiting, while WebKitGTK+ tries to do something with glib's GSource object, which might be just a coincidence. Could you try to run evolution from a terminal, please? Maybe it'll show a reason why it is exiting.
No idea sorry, it was only once and work ok since that. Maybe hardware glitch (old 3770k CPU here)
*** Bug 1708878 has been marked as a duplicate of this bug. ***
I'm moving this to WebKitGTK+. I noticed the runtime warnings being shown sometimes here too, on Fedora 30 more often, I think, though it didn't crash here, it only reported the runtime warning and it was all.
Yes, this is definitely a WebKitGTK bug. I've had no luck debugging it, though, as I don't see what's wrong. It happens in MiniBrowser frequently, but not often enough to be reproducible.
I can reproduce it with webkit2gtk3-2.24.1-1.fc30.x86_64, evolution-3.32.2-1.fc30.x86_64 and glib2-2.60.2-1.fc30.x86_64, when I: a) run from terminal: evolution --offline b) once the UI maps press Ctrl+Shift+M (this opens a new mail message composer) c) once the composer is open, press Esc (this closes the composer) d) press Alt+F, Arrow-Up, Enter (this quits the application, similar to Alt+F4 or Ctrl+Q). It's almost always there, even when run under gdb, but it can be tricky under valgrind, where the memory checking seems to cause enough delays that it makes the code work fine. I managed to catch it, without debuginfo for webkit2gtk3 (I'm sorry, but I fight with the disk space on the machine), under valgrind, I hope it'll give you at least an idea about the place of the issue: ==5520== Thread 30 ReceiveQueue: ==5520== Invalid read of size 8 ==5520== at 0x54F7EED: g_source_set_ready_time (gmain.c:1850) ==5520== by 0x5CB2C10: ??? (in /usr/lib64/libwebkit2gtk-4.0.so.37.37.3) ==5520== by 0xB3E6630: ??? (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0xB39CB40: WTF::RunLoop::performWork() (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0xB3E6CBC: ??? (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0x54F9FCF: g_main_dispatch (gmain.c:3189) ==5520== by 0x54F9FCF: g_main_context_dispatch (gmain.c:3854) ==5520== by 0x54FA367: g_main_context_iterate.isra.0 (gmain.c:3927) ==5520== by 0x54FA6B2: g_main_loop_run (gmain.c:4123) ==5520== by 0xB3E771F: WTF::RunLoop::run() (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0xB39DFB7: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0xB3E7A9C: ??? (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0x4A115A1: start_thread (in /usr/lib64/libpthread-2.29.so) ==5520== by 0x8775162: clone (in /usr/lib64/libc-2.29.so) ==5520== Address 0x191aa048 is 88 bytes inside a block of size 96 free'd ==5520== at 0x4839A0C: free (vg_replace_malloc.c:540) ==5520== by 0x54FFEBC: g_free (gmem.c:192) ==5520== by 0x54F7066: g_source_unref_internal (gmain.c:2172) ==5520== by 0xB3E719C: WTF::RunLoop::TimerBase::~TimerBase() (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0x86B46BF: __run_exit_handlers (in /usr/lib64/libc-2.29.so) ==5520== by 0x86B47FF: exit (in /usr/lib64/libc-2.29.so) ==5520== by 0x869DF39: (below main) (in /usr/lib64/libc-2.29.so) ==5520== Block was alloc'd at ==5520== at 0x483AB1A: calloc (vg_replace_malloc.c:762) ==5520== by 0x54FFE20: g_malloc0 (gmem.c:129) ==5520== by 0x54F785D: g_source_new (gmain.c:917) ==5520== by 0xB3E710F: WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&) (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0xB3E63A2: WTF::scheduleDispatchFunctionsOnMainThread() (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0x5CB2C10: ??? (in /usr/lib64/libwebkit2gtk-4.0.so.37.37.3) ==5520== by 0xB3E6630: ??? (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0xB39CB40: WTF::RunLoop::performWork() (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0xB3E6CBC: ??? (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0x54F9FCF: g_main_dispatch (gmain.c:3189) ==5520== by 0x54F9FCF: g_main_context_dispatch (gmain.c:3854) ==5520== by 0x54FA367: g_main_context_iterate.isra.0 (gmain.c:3927) ==5520== by 0x54FA6B2: g_main_loop_run (gmain.c:4123) ==5520== by 0xB3E771F: WTF::RunLoop::run() (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0xB39DFB7: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0xB3E7A9C: ??? (in /usr/lib64/libjavascriptcoregtk-4.0.so.18.13.4) ==5520== by 0x4A115A1: start_thread (in /usr/lib64/libpthread-2.29.so) ==5520== by 0x8775162: clone (in /usr/lib64/libc-2.29.so) ==5520== (evolution:5520): GLib-CRITICAL **: 16:08:35.467: g_source_set_ready_time: assertion 'source->priv != NULL' failed
Michael, move it to upstream? I cannot provide more detailed valgrind report, I do not have much disk space for the webkit2gtk3 debuginfo, but if you think it's fine just as it is, then I can move this there and close this accordingly (as Upstream).
I think this is https://bugs.webkit.org/show_bug.cgi?id=197266.
Yup, from the ABRT backtrace I see it's the same place in the connection code, and while running exit handlers in a different thread.
Nice, thanks for finding the upstream bug.