210561 2020-04-15 11:46:57 -0700 [GTK] excessive wakeups/polling due to gdk_frame_clock_begin_updating 2020-04-29 23:37:39 -0700 1 1 1 Unclassified WebKit WebKitGTK Other PC Linux RESOLVED FIXED P2 Normal --- 1 webkit webkit-unassigned berto bugs-noreply calestyo cgarcia clopez mcatanzaro mcrha pnormand svillar zan oldest_to_newest 1641899 0 webkit 2020-04-15 11:46:57 -0700 Since upgrading to 2.28, /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess drains my laptop battery like crazy: $ ps axfu [...] tomi 243322 15.0 0.2 102683612 96224 ? Sl 17:53 0:00 liferea tomi 243332 4.7 0.2 102722076 90816 ? SLl 17:53 0:00 \_ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 7 19 tomi 243333 1.5 0.1 103007620 53204 ? SLl 17:53 0:00 \_ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess 8 1 $ LANG=C strace -f -p 243332 strace: Process 243332 attached with 11 threads [pid 243360] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 243359] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 243357] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 243356] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 243355] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 243344] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 243343] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 243342] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 243341] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 243340] futex(0x7f14fb18c7cc, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...> [pid 243332] restart_syscall(<... resuming interrupted read ...>) = 0 [pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 17) = 0 (Timeout) [pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0 (Timeout) [pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0 (Timeout) [pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0 (Timeout) [pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 15) = 0 (Timeout) [pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0 (Timeout) [pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0 (Timeout) It's not necessary to run liferea, it's reproducible just by "surf about:blank", so I tried to gdb the process to see what's going on. By breaking at ../../../glib/gmain.c:3677 and looking for small enough source_timeout, I found this: (gdb) print *source $8 = {callback_data = 0x562da2385070, callback_funcs = 0x7f4824f32280 <g_source_callback_funcs>, source_funcs = 0x7f4824f32340 <g_timeout_funcs>, ref_count = 2, context = 0x562da20fa910, priority = 120, flags = 1, source_id = 29853, poll_fds = 0x0, prev = 0x0, next = 0x0, name = 0x562da243f320 "[gtk+] gdk_frame_clock_paint_idle", priv = 0x562da239ead0} So it seems something is calling gdk_frame_clock_begin_updating without a matching gdk_frame_clock_end_updating... Well, there's just one call to gdk_frame_clock_begin_updating in the entire webkit source and no call to gdk_frame_clock_end_updating so we just need to find why that's getting called: Thread 2.1 "WebKitWebProces" hit Breakpoint 2, gdk_frame_clock_begin_updating (frame_clock=0x555abd120590 [GdkFrameClockIdle]) at ../../../../gdk/gdkframeclock.c:319 (gdb) bt #0 gdk_frame_clock_begin_updating (frame_clock=0x555abd120590 [GdkFrameClockIdle]) at ../../../../gdk/gdkframeclock.c:319 #1 0x00007f34a3b15e49 in WebCore::DisplayRefreshMonitorGtk::requestRefreshCallback() () at ../Source/WebCore/platform/graphics/gtk/DisplayRefreshMonitorGtk.cpp:67 #2 0x00007f34a39afa4a in WebCore::RenderingUpdateScheduler::scheduleTimedRenderingUpdate() () at ../Source/WebCore/page/RenderingUpdateScheduler.cpp:59 #3 WebCore::RenderingUpdateScheduler::scheduleTimedRenderingUpdate() () at ../Source/WebCore/page/RenderingUpdateScheduler.cpp:45 #4 0x00007f34a3982129 in WTF::Function<void (WebCore::Document&)>::operator()(WebCore::Document&) const () at DerivedSources/ForwardingHeaders/wtf/Function.h:84 #5 WebCore::Page::forEachDocument(WTF::Function<void (WebCore::Document&)> const&) const () at ../Source/WebCore/page/Page.cpp:2843 #6 0x00007f34a398225b in WebCore::Page::updateStyleAfterChangeInEnvironment() () at ../Source/WebCore/page/Page.cpp:574 #7 0x00007f34a39822e5 in WebCore::Page::updateStyleForAllPagesAfterGlobalChangeInEnvironment() () at ../Source/WebCore/page/Page.cpp:586 #8 0x00007f34a2992656 in WebKit::WebPage::themeDidChange(WTF::String&&) () at ../Source/WebKit/WebProcess/WebPage/gtk/WebPageGtk.cpp:167 #9 0x00007f34a2974f79 in WebKit::WebPage::WebPage(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) () at ../Source/WebKit/WebProcess/WebPage/WebPage.cpp:604 #10 0x00007f34a29757fe in WebKit::WebPage::create(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) () at ../Source/WebKit/WebProcess/WebPage/WebPage.cpp:379 #11 0x00007f34a27e36fc in WebKit::WebProcess::createWebPage(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&) () at ../Source/WebKit/WebProcess/WebProcess.cpp:685 #12 0x00007f34a24307d7 in IPC::callMemberFunctionImpl<WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>, 0ul, 1ul>(WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>&&, std::integer_sequence<unsigned long, 0ul, 1ul>) () at ../Source/WebKit/Platform/IPC/HandleMessage.h:41 #13 IPC::callMemberFunction<WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&), std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>, std::integer_sequence<unsigned long, 0ul, 1ul> >(std::tuple<WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters>&&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)) () at ../Source/WebKit/Platform/IPC/HandleMessage.h:47 #14 IPC::handleMessage<Messages::WebProcess::CreateWebPage, WebKit::WebProcess, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)>(IPC::Decoder&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(WTF::ObjectIdentifier<WebCore::PageIdentifierType>, WebKit::WebPageCreationParameters&&)) () at ../Source/WebKit/Platform/IPC/HandleMessage.h:120 #15 0x00007f34a2429c5b in WebKit::WebProcess::didReceiveWebProcessMessage(IPC::Connection&, IPC::Decoder&) () at DerivedSources/WebKit/WebProcessMessageReceiver.cpp:291 #16 0x00007f34a2580460 in IPC::Connection::dispatchMessage(IPC::Decoder&) () at ../Source/WebKit/Platform/IPC/Connection.cpp:1008 #17 0x00007f34a25817d5 in IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) () at ../Source/WebKit/Platform/IPC/Connection.cpp:1077 #18 0x00007f34a2581e9b in IPC::Connection::dispatchOneIncomingMessage() () at ../Source/WebKit/Platform/IPC/Connection.cpp:1146 #19 0x00007f34a03c4cac in WTF::RunLoop::performWork() () at /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18 #20 0x00007f34a0412ae9 in () at /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18 #21 0x00007f34a0b9f4de in g_main_dispatch (context=0x555abd114690) at ../../../glib/gmain.c:3309 #22 g_main_context_dispatch (context=context@entry=0x555abd114690) at ../../../glib/gmain.c:3974 #23 0x00007f34a0b9f890 in g_main_context_iterate (context=0x555abd114690, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:4047 #24 0x00007f34a0b9fb63 in g_main_loop_run (loop=0x555abd159c50) at ../../../glib/gmain.c:4241 #25 0x00007f34a0413548 in WTF::RunLoop::run() () at /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18 #26 0x00007f34a299af8f in WebKit::AuxiliaryProcessMain<WebKit::WebProcess, WebKit::WebProcessMainGtk>(int, char**) () at ../Source/WebKit/Shared/AuxiliaryProcessMain.h:68 #27 0x00007f34a1a2de0b in __libc_start_main (main= 0x555abb1ef760 <main()>, argc=3, argv=0x7ffcb4760f68, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcb4760f58) at ../csu/libc-start.c:308 #28 0x0000555abb1ef7ea in _start () The document.scheduleTimedRenderingUpdate invocation in Page::updateStyleAfterChangeInEnvironment is definitely new in 2.28, but it does seem weird that any scheduleTimedRenderingUpdate invocation across webkit would lead to 60 wakeups per second forever and ever... Indeed, it seems that opening https://en.wikipedia.org/wiki/GIF#/media/File:Rotating_earth_(large).gif invokes scheduleTimedRenderingUpdate and even after switching to about:blank, this process continues waking up more than 60 times per second. So this is not really a 2.28 regression, it just got worse and is triggered by any web page, not just those that actually move. Perhaps DisplayRefreshMonitorGtk::~DisplayRefreshMonitorGtk should call gdk_frame_clock_end_updating? But then, when I browse for a while and then attach gdb, break on gdk_frame_clock_paint_idle and print *priv, I get: $2 = {frame_time = 51614508992, min_next_frame_time = 51614525659, sleep_serial = 7357, freeze_time = 0, flush_idle_id = 0, paint_idle_id = 11239, freeze_count = 0, updating_count = 1, requested = GDK_FRAME_CLOCK_PHASE_NONE, phase = GDK_FRAME_CLOCK_PHASE_NONE, in_paint_idle = 0} updating_count is 1, so it doesn't seem like gdk_frame_clock_begin_updating is getting called multiple times, and thus calling gdk_frame_clock_end_updating is unlikely to help. But it seems WebCore::RenderingUpdateScheduler::scheduleTimedRenderingUpdate (and thus also WebCore::DisplayRefreshMonitorGtk::requestRefreshCallback) _is_ getting called fairly often, so maybe this whole gdk_frame_clock_begin_updating is actually a mistake and we should be calling gdk_frame_clock_request_phase instead? More info about that here: https://developer.gnome.org/gdk3/stable/GdkFrameClock.html 1642183 1 cgarcia 2020-04-16 02:04:50 -0700 Thanks for the so detailed bug report. We have noticed this, but it wasn't always reproducible for me. I assumed we were leaking a DisplayRefreshMonitor at some point, but it seems we don't, and maybe the problem is the way we use the GdkFrameClock. 1642186 2 cgarcia 2020-04-16 02:42:54 -0700 The reason why we don't call end_updating is because we assume the frame clock is destroyed when the offscreen window is destroyed. 1642190 3 cgarcia 2020-04-16 03:32:34 -0700 I've tried to reproduce this again with MiniBrowser, evolution and liferea and I still can't reproduce it :-( 1642191 4 webkit 2020-04-16 04:09:20 -0700 > I've tried to reproduce this again with MiniBrowser, evolution and liferea and I still can't reproduce it :-( Weird. :-/ I can reproduce it with 2.28.1 just by launching liferea, or by launching surf about:blank and then stracing the WebKitWebProcess. With 2.26.4 surf about:blank is okay, but surf https://en.wikipedia.org/wiki/GIF#/media/File:Rotating_earth_(large).gif triggers it. 1642192 5 webkit 2020-04-16 04:09:42 -0700 I should also say that my system is amd64 Debian testing. 1642214 6 cgarcia 2020-04-16 05:48:05 -0700 Just to be clear, I see the GdkFrameClock being used, but it's correctly destroyed as expected. 1642216 7 webkit 2020-04-16 05:57:09 -0700 Perhaps you have a different version of gtk that fixed/worked around this? Or maybe it's a difference between X11 and Wayland backends? I'm using X11 and gtk 3.24.18. 1642218 8 webkit 2020-04-16 06:03:42 -0700 Anyway, if you want the offscreen window destruction to clean things up, perhaps https://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-add-tick-callback is better than gdk_frame_clock_begin_updating? (BTW, if you want a more interactive communication channel, I'm Liskni_si on freenode and @Liskni_si on Twitter.) 1642249 9 cgarcia 2020-04-16 07:33:32 -0700 (In reply to Tomáš Janoušek from comment #7) > Perhaps you have a different version of gtk that fixed/worked around this? > Or maybe it's a difference between X11 and Wayland backends? I'm using X11 > and gtk 3.24.18. Maybe, I don't think it's X11 or wayland specific, because other people reported the problem with evolution under wayland. 1642250 10 cgarcia 2020-04-16 07:34:39 -0700 (In reply to Tomáš Janoušek from comment #8) > Anyway, if you want the offscreen window destruction to clean things up, > perhaps > https://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-add-tick- > callback is better than gdk_frame_clock_begin_updating? I've checked the GdkFrameClock is properly destroyed. > (BTW, if you want a more interactive communication channel, I'm Liskni_si on > freenode and @Liskni_si on Twitter.) I'll ping you tomorrow on IRC then. Thanks! 1643445 11 calestyo 2020-04-20 07:39:28 -0700 Hey. Probably the following has nothing to do with this bug (which I'm also experiencing in at least Evolution): Could it be that this issue is somehow caused by a kernel change (specifically something that happened in kernels >5.2)? I see this pattern of fast: pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 17) = 0 (Timeout) in quite a number of applications (e.g. diodon is one: https://bugs.launchpad.net/diodon/+bug/1871008 ... and I've also noticed it in cinnamon https://github.com/linuxmint/cinnamon/issues/9085#issuecomment-615543487 ) These in turn are all programs which might play a part in a bigger issue I suffer since kernels >5.2, namely some massive increase of CPU temperature respectively power consumption for GPU but also non-GPU intensive workloads: see: https://bugzilla.kernel.org/show_bug.cgi?id=207245 (with links to other related bug reports) for more details. Cheers, Chris. 1643454 12 mcatanzaro 2020-04-20 08:21:03 -0700 If I were you, I would try bisecting the kernel. 1643468 13 webkit 2020-04-20 09:04:11 -0700 Christoph Anton Mitterer, yeah, if you're running several apps that each use WebKitGtk and suffer from this issue, that would indeed make your CPU considerably hotter. I'm lucky to just be running one and I still had to downgrade. :-) Anyway, I added a reply here as well: https://gitlab.freedesktop.org/drm/intel/-/issues/953#note_470483 because I think the kernel issue may not be fully fixed either, and might be making it worse. 1644637 14 calestyo 2020-04-22 19:56:31 -0700 @Michael: Well that's probably the next thing on the road. @Tomáš: Thanks for your comments, though I kinda doubt that the WebKit issue is the only reason for my problems (see e.g. my extensive tests, which show that even without Evolution or any GUI activity, there's a huge difference between 5.2 and 5.5 (worse)... and within each between intel_pstate being enabled (worse) and not. Having e.g. Evolution run with some WebKit process being in the state of high CPU utilisation (which is likely this bug), just makes it worse. Could anyone else check whether he sees *this* issue here, with much older kernels (i.e. 5.2 and below)? Also, any fix for this on the horizon? :-) 1644689 15 cgarcia 2020-04-22 22:29:57 -0700 (In reply to Christoph Anton Mitterer from comment #14) > @Michael: Well that's probably the next thing on the road. > > @Tomáš: Thanks for your comments, though I kinda doubt that the WebKit issue > is the only reason for my problems (see e.g. my extensive tests, which show > that even without Evolution or any GUI activity, there's a huge difference > between 5.2 and 5.5 (worse)... and within each between intel_pstate being > enabled (worse) and not. > > Having e.g. Evolution run with some WebKit process being in the state of > high CPU utilisation (which is likely this bug), just makes it worse. > > > Could anyone else check whether he sees *this* issue here, with much older > kernels (i.e. 5.2 and below)? > > Also, any fix for this on the horizon? :-) I need to reproduce it to fix it. Or some help from someone who can reproduce it to debug the issue and understand the problem. Another solution might be to forget about GdkFrameClock and use a simple timer at 60fps. 1644707 16 webkit 2020-04-23 01:14:55 -0700 > I need to reproduce it to fix it. Or some help from someone who can reproduce it to debug the issue and understand the problem. Another solution might be to forget about GdkFrameClock and use a simple timer at 60fps. I'd love to help but I don't know what else I can do here. Any ideas? Last week you said you'd ping me on IRC on Friday... :-/ 1644756 17 397337 cgarcia 2020-04-23 07:08:54 -0700 Created attachment 397337 Patch Finally found the problem with help from Tomáš. Thanks! 1644761 18 cgarcia 2020-04-23 07:33:31 -0700 Committed r260567: <https://trac.webkit.org/changeset/260567> 1644762 19 397337 svillar 2020-04-23 07:33:52 -0700 Comment on attachment 397337 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=397337&action=review Awesome! > Source/WebCore/platform/graphics/gtk/DisplayRefreshMonitorGtk.cpp:50 > + gtk_widget_destroy(m_window); Do we really need the destroy? Isn't it enough with calling _end_updating() 1644763 20 svillar 2020-04-23 07:34:50 -0700 (In reply to Sergio Villar Senin from comment #19) > Comment on attachment 397337 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=397337&action=review > > Awesome! > > > Source/WebCore/platform/graphics/gtk/DisplayRefreshMonitorGtk.cpp:50 > > + gtk_widget_destroy(m_window); > > Do we really need the destroy? Isn't it enough with calling _end_updating() Beh, I've just realized that we're already calling it, nevermind. 1644789 21 mcrha 2020-04-23 09:08:39 -0700 Is it good idea to: ASSERT(frameClock); on both places? The gtk_widget_get_frame_clock() can return NULL, according to its documentation. You can also use g_signal_handlers_disconnect_by_data(), which was added in glib 2.32. I do not see which version of glib WebKitGTK depends on (not from FindGLIB.cmake at least). 1644796 22 clopez 2020-04-23 09:22:00 -0700 (In reply to Milan Crha from comment #21) > You can also use g_signal_handlers_disconnect_by_data(), which was added in > glib 2.32. I do not see which version of glib WebKitGTK depends on (not from > FindGLIB.cmake at least). It's currently set to 2.44 in Source/cmake/OptionsGTK.cmake:find_package(GLIB 2.44.0 REQUIRED COMPONENTS gio gio-unix gobject gthread gmodule) And it would be OK to raise that minimum version to 2.56 (its what ships Ubuntu-18.04) 1644798 23 mcrha 2020-04-23 09:24:24 -0700 (In reply to Carlos Alberto Lopez Perez from comment #22) > ...And it would be OK to raise that minimum version... No need to raise it, from my point of view. As long as you use API in the old version it's all fine. 1645121 24 cgarcia 2020-04-24 01:17:55 -0700 (In reply to Milan Crha from comment #21) > Is it good idea to: > > ASSERT(frameClock); > > on both places? The gtk_widget_get_frame_clock() can return NULL, according > to its documentation. Yes, but in this case we are creating a toplevel that we manually realize, so the frame clock is already created for sure. > You can also use g_signal_handlers_disconnect_by_data(), which was added in > glib 2.32. I do not see which version of glib WebKitGTK depends on (not from > FindGLIB.cmake at least). I guess it doesn't matter unless it's more efficient. 1645124 25 mcrha 2020-04-24 01:33:21 -0700 (In reply to Carlos Garcia Campos from comment #24) > I guess it doesn't matter unless it's more efficient. I doubt it's more efficient. I suggested it rather for readability/convenience. Nothing important. 1647222 26 calestyo 2020-04-29 17:31:19 -0700 Hey guys. I've got the fix no with some recent Debian package,... and the extreme CPU utilisations are in fact fixed. However, I still see some little sporadic CPU utilisation from Evolution's WebKit processes every now and then... really nothing dramatic, most of the time they're 0%, however they do go up to say 2-3,3% every once in a while, *even though nothing happens at Evolution* (like I do not select any other mail, so that content would have to be re-drawn, nor are there any animated GIFs or so). It even happens when Evolution is minimised. Is this kinda expected or something that one should follow up. Thanks, Chris. 1647298 27 mcrha 2020-04-29 23:37:39 -0700 Evolution can invoke repaint of the message preview, indirectly, when the theme style changes. It can happen also when the window gets focus or loses it. I currently do not know what else could cause that, not periodically. Maybe install debuginfo for (or build with it) the evolution itself (not WebKit, it's too huge) and when it happens, supposing there will be enough time to do it, catch a series of backtraces of the offending process, which may or may not shed a bit of light on this. I catch backtraces with this command: for i in {1..10}; do gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt$i.txt; sleep 0.1; done You can tweak the delay between them with the sleep command (set to 100ms in the command). The backtraces may not expose any private information, but, please, check the files for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only). Just in case. I do not know whether we should keep this here, as the bug itself is fixed. Feel free to open a new bug on the evolution side and we can investigate there [1]. [1] https://gitlab.gnome.org/GNOME/evolution/issues/new 397337 2020-04-23 07:08:54 -0700 2020-04-23 07:14:54 -0700 Patch wkgtk-frame-clock.diff text/plain 2884 cgarcia ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZyBiL1NvdXJjZS9XZWJDb3JlL0No YW5nZUxvZwppbmRleCA2MGY1NTNjMDYwNTAuLjVmMjdiNWMyNjRmNCAxMDA2NDQKLS0tIGEvU291 cmNlL1dlYkNvcmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwpAQCAt MSwzICsxLDIzIEBACisyMDIwLTA0LTIzICBDYXJsb3MgR2FyY2lhIENhbXBvcyAgPGNnYXJjaWFA aWdhbGlhLmNvbT4KKworICAgICAgICBbR1RLXSBleGNlc3NpdmUgd2FrZXVwcy9wb2xsaW5nIGR1 ZSB0byBnZGtfZnJhbWVfY2xvY2tfYmVnaW5fdXBkYXRpbmcKKyAgICAgICAgaHR0cHM6Ly9idWdz LndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIxMDU2MQorCisgICAgICAgIFJldmlld2VkIGJ5 IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFRoZSBwcm9ibGVtIGlzIHRoYXQgd2UgYXJlIGRl c3Ryb3lpbmcgdGhlIGRpc3BsYXkgcmVmcmVzaCBtb25pdG9yIGZyb20gdGhlIGZyYW1lIGNsb2Nr IHVwZGF0ZSBjYWxsYmFjaywgYW5kIEdUSworICAgICAgICBzY2hlZHVsZXMgYW5vdGhlciB1cGRh dGUgZnJvbSB0aGUgY2FsbGJhY2sgaXRzZWxmIGluIHNvbWUgY2FzZXMsIHdoaWNoIGVuZHMgdXAg aGFwcGVuaW5nIGZvcmV2ZXIuIFdlIHdlcmUKKyAgICAgICAgYXNzdW1pbmcgdGhhdCBkZXN0cm95 aW5nIHRoZSB3aW5kb3cgb2YgaW1tZWRpYXRlbHkgZGVzdHJveSB0aGUgZnJhbWUgY2xvY2sgYXMg d2VsbCwgYnV0IHRoZSBwYWludCBzb3VyY2UgaWRsZQorICAgICAgICBrZWVwcyBhIHJlZmVyZW5j ZSBvZiB0aGUgZnJhbWUgY2xvY2suIEF0IHRoZSBlbmQgb2YgdGhlIHNvdXJjZSBpZGxlIGNhbGxi YWNrIHRoZSBzb3VyY2UgaXMgc2NoZWR1bGVkIGFnYWluLAorICAgICAgICB0YWtpbmcgYSBuZXcg cmVmZXJlbmNlLiBXZSBuZWVkIHRvIGNhbGwgZ2RrX2ZyYW1lX2Nsb2NrX2VuZF91cGRhdGluZygp IHRvIGVuc3VyZSB0aGUgaWRsZSBpcyBub3Qgc2NoZWR1bGVkCisgICAgICAgIGFnYWluLgorCisg ICAgICAgICogcGxhdGZvcm0vZ3JhcGhpY3MvZ3RrL0Rpc3BsYXlSZWZyZXNoTW9uaXRvckd0ay5j cHA6CisgICAgICAgIChXZWJDb3JlOjpEaXNwbGF5UmVmcmVzaE1vbml0b3JHdGs6On5EaXNwbGF5 UmVmcmVzaE1vbml0b3JHdGspOiBEaXNjb25uZWN0IHRoZSB1cGRhdGUgc2lnbmFsIGFuZCBjYWxs CisgICAgICAgIGdka19mcmFtZV9jbG9ja19lbmRfdXBkYXRpbmcoKS4KKyAgICAgICAgKFdlYkNv cmU6OkRpc3BsYXlSZWZyZXNoTW9uaXRvckd0azo6cmVxdWVzdFJlZnJlc2hDYWxsYmFjayk6IFRv cGxldmVsIHdpbmRvdyBzaG91bGQgYWx3YXlzIGhhdmUgYSBmcmFtZSBjbG9jaywKKyAgICAgICAg c28gcmVtb3ZlIHRoZSBlYXJseSByZXR1cm4gYW5kIGFkZCBhbiBhc3NlcnQgaW5zdGVhZC4KKwog MjAyMC0wMy0yNSAgVGluZy1XZWkgTGFuICA8bGFudHc0NEBnbWFpbC5jb20+CiAKICAgICAgICAg W0dUS10gQWRkIHVzZXIgYWdlbnQgcXVpcmsgZm9yIGF1dGgubWF5b2hyLmNvbQpkaWZmIC0tZ2l0 IGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvZ3RrL0Rpc3BsYXlSZWZyZXNoTW9u aXRvckd0ay5jcHAgYi9Tb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9ndGsvRGlzcGxh eVJlZnJlc2hNb25pdG9yR3RrLmNwcAppbmRleCAxMjVmZTRiNTM2ZjQuLjA5YThiODVkODBhZiAx MDA2NDQKLS0tIGEvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhpY3MvZ3RrL0Rpc3BsYXlS ZWZyZXNoTW9uaXRvckd0ay5jcHAKKysrIGIvU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vZ3JhcGhp Y3MvZ3RrL0Rpc3BsYXlSZWZyZXNoTW9uaXRvckd0ay5jcHAKQEAgLTQwLDggKzQwLDE0IEBAIERp c3BsYXlSZWZyZXNoTW9uaXRvckd0azo6RGlzcGxheVJlZnJlc2hNb25pdG9yR3RrKFBsYXRmb3Jt RGlzcGxheUlEIGRpc3BsYXlJRCkKIAogRGlzcGxheVJlZnJlc2hNb25pdG9yR3RrOjp+RGlzcGxh eVJlZnJlc2hNb25pdG9yR3RrKCkKIHsKLSAgICBpZiAobV93aW5kb3cpCi0gICAgICAgIGd0a193 aWRnZXRfZGVzdHJveShtX3dpbmRvdyk7CisgICAgaWYgKCFtX3dpbmRvdykKKyAgICAgICAgcmV0 dXJuOworCisgICAgYXV0byogZnJhbWVDbG9jayA9IGd0a193aWRnZXRfZ2V0X2ZyYW1lX2Nsb2Nr KG1fd2luZG93KTsKKyAgICBBU1NFUlQoZnJhbWVDbG9jayk7CisgICAgZ19zaWduYWxfaGFuZGxl cnNfZGlzY29ubmVjdF9tYXRjaGVkKGZyYW1lQ2xvY2ssIEdfU0lHTkFMX01BVENIX0RBVEEsIDAs IDAsIG51bGxwdHIsIG51bGxwdHIsIHRoaXMpOworICAgIGdka19mcmFtZV9jbG9ja19lbmRfdXBk YXRpbmcoZnJhbWVDbG9jayk7CisgICAgZ3RrX3dpZGdldF9kZXN0cm95KG1fd2luZG93KTsKIH0K IAogc3RhdGljIHZvaWQgb25GcmFtZUNsb2NrVXBkYXRlKEdka0ZyYW1lQ2xvY2sqLCBEaXNwbGF5 UmVmcmVzaE1vbml0b3JHdGsqIG1vbml0b3IpCkBAIC02MCw4ICs2Niw3IEBAIGJvb2wgRGlzcGxh eVJlZnJlc2hNb25pdG9yR3RrOjpyZXF1ZXN0UmVmcmVzaENhbGxiYWNrKCkKICAgICAgICAgZ3Rr X3dpZGdldF9yZWFsaXplKG1fd2luZG93KTsKIAogICAgICAgICBhdXRvKiBmcmFtZUNsb2NrID0g Z3RrX3dpZGdldF9nZXRfZnJhbWVfY2xvY2sobV93aW5kb3cpOwotICAgICAgICBpZiAoIWZyYW1l Q2xvY2spCi0gICAgICAgICAgICByZXR1cm4gZmFsc2U7CisgICAgICAgIEFTU0VSVChmcmFtZUNs b2NrKTsKIAogICAgICAgICBnX3NpZ25hbF9jb25uZWN0KGZyYW1lQ2xvY2ssICJ1cGRhdGUiLCBH X0NBTExCQUNLKG9uRnJhbWVDbG9ja1VwZGF0ZSksIHRoaXMpOwogICAgICAgICBnZGtfZnJhbWVf Y2xvY2tfYmVnaW5fdXBkYXRpbmcoZnJhbWVDbG9jayk7Cg==