Bug 775537 – Preview display stops updating

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 775537 - Preview display stops updating


Summary:	Preview display stops updating


Status:	RESOLVED FIXED

Product:	evolution
Classification:	Applications
Component:	Shell
Version:	3.22.x (obsolete)
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	---
Assigned To:	Evolution Shell Maintainers Team
QA Contact:	Evolution QA team

URL:
Whiteboard:

Duplicates:	772660 (view as bug list)
Depends on:
Blocks:

Reported:	2016-12-02 22:45 UTC by Pete Biggs
Modified:	2017-01-19 17:14 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
Backtrace for Evolution when preview window stops updating (29.61 KB, text/plain) 2016-12-02 22:45 UTC, Pete Biggs	Details
Backtrace for WebKitWebProcess when preview window stops updating (25.39 KB, text/plain) 2016-12-02 22:46 UTC, Pete Biggs	Details

Description Pete Biggs 2016-12-02 22:45:51 UTC

Created attachment 341276 [details]
Backtrace for Evolution when preview window stops updating

I've just recently upgraded to Fedora 25 with Evolution 3.22.2.

Randomly the preview window stops updating when I change message - the
contents of the window just stay the same no matter which message I
select. Turning the preview on and off doesn't help, neither does going
offline. Double clicking on the message to display it in a new window also
doesn't work (i.e. the window remains grey).

There doesn't seem to be any consistent type of message that causes it 
and it happens with both Wayland and Xorg.

Knowing that the WebKit version for 3.22 has changed I've found that
killing the "WebKitWebProcess" process fixes things for a little while.

Comment 1 Pete Biggs 2016-12-02 22:46:58 UTC

Created attachment 341277 [details]
Backtrace for WebKitWebProcess when preview window stops updating

Comment 2 Milan Crha 2016-12-05 13:08:02 UTC

*** Bug 772660 has been marked as a duplicate of this bug. ***

Comment 3 Milan Crha 2016-12-05 13:13:48 UTC

Thanks for a bug report. Looking at the WebKitWebProcess backtrace, its main thread is stuck in some threaded rendering, blocking all other requests. This looks like a valid issue in the WebKitGTK+ to me, but I do not know it enough.

Could you try to run evolution from a terminal like this:

   $ WEBKIT_DISABLE_COMPOSITING_MODE=1 evolution

to see whether it'll help, please?

Comment 4 Milan Crha 2016-12-05 13:15:11 UTC

I'm pasting the main thread backtrace of WebKitWebProcess here, for easier searching:

+ Trace 236923

Thread 1 (Thread 0x7f85c17bafc0 (LWP 3177))

#0 pthread_cond_wait
at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S line 185
#1 __gthread_cond_wait
at /usr/src/debug/gcc-6.2.1-20160916/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/x86_64-redhat-linux/bits/gthr-default.h line 864
#2 std::condition_variable::wait(std::unique_lock<std::mutex>&)
at ../../../../../libstdc++-v3/src/c++11/condition_variable.cc line 53
#3 WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >)
at /usr/src/debug/webkitgtk-2.14.2/Source/WTF/wtf/ParkingLot.cpp line 601
#4 WTF::ParkingLot::parkConditionally<bool WTF::ConditionBase::waitUntil<WTF::Lock>(WTF::Lock&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >)::{lambda()#1}, bool WTF::ConditionBase::waitUntil<WTF::Lock>(WTF::Lock&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >)::{lambda()#2}>(void const*, bool WTF::ConditionBase::waitUntil<WTF::Lock>(WTF::Lock&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >)::{lambda()#1} const&, bool WTF::ConditionBase::waitUntil<WTF::Lock>(WTF::Lock&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >)::{lambda()#2} const&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >)
at /usr/src/debug/webkitgtk-2.14.2/Source/WTF/wtf/ParkingLot.h line 77
#5 WTF::ConditionBase::waitUntil<WTF::Lock>(WTF::Lock&, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >)
at /usr/src/debug/webkitgtk-2.14.2/Source/WTF/wtf/Condition.h line 74
#6 WTF::ConditionBase::wait<WTF::Lock>(WTF::Lock&)
at /usr/src/debug/webkitgtk-2.14.2/Source/WTF/wtf/Condition.h line 113
#7 WebKit::CompositingRunLoop::performTaskSync(WTF::Function<void ()>&&)
at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp line 140
#8 WebKit::ThreadedCompositor::setViewportSize(WebCore::IntSize const&, float)
at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp line 117
#9 WebKit::ThreadedCoordinatedLayerTreeHost::sizeDidChange(WebCore::IntSize const&)
at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/WebProcess/WebPage/CoordinatedGraphics/ThreadedCoordinatedLayerTreeHost.cpp line 125
#10 WebKit::AcceleratedDrawingArea::updateBackingStoreState(unsigned long, bool, float, WebCore::IntSize const&, WebCore::IntSize const&)
at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/WebProcess/WebPage/AcceleratedDrawingArea.cpp line 234
#11 WebKit::DrawingAreaImpl::updateBackingStoreState(unsigned long, bool, float, WebCore::IntSize const&, WebCore::IntSize const&)
at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.cpp line 218
#12 IPC::callMemberFunctionImpl<WebKit::DrawingArea, void
#13 IPC::callMemberFunction<WebKit::DrawingArea, void
#14 IPC::handleMessage<Messages::DrawingArea::UpdateBackingStoreState, WebKit::DrawingArea, void
#15 WebKit::DrawingArea::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
at /usr/src/debug/webkitgtk-2.14.2/x86_64-redhat-linux-gnu/DerivedSources/WebKit2/DrawingAreaMessageReceiver.cpp line 61
#16 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&)
at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/Platform/IPC/MessageReceiverMap.cpp line 123
#17 WebKit::WebProcess::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/WebProcess/WebProcess.cpp line 649
#18 IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >)
at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/Platform/IPC/Connection.cpp line 858
#19 IPC::Connection::dispatchOneMessage()
at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/Platform/IPC/Connection.cpp line 889
#20 WTF::Function<void
#21 WTF::RunLoop::performWork()
at /usr/src/debug/webkitgtk-2.14.2/Source/WTF/wtf/RunLoop.cpp line 105
#22 WTF::RunLoop::<lambda(gpointer)>::operator()
at /usr/src/debug/webkitgtk-2.14.2/Source/WTF/wtf/glib/RunLoopGLib.cpp line 66
#23 WTF::RunLoop::<lambda(gpointer)>::_FUN(gpointer)
at /usr/src/debug/webkitgtk-2.14.2/Source/WTF/wtf/glib/RunLoopGLib.cpp line 68
#24 g_main_dispatch
at gmain.c line 3203
#25 g_main_context_dispatch
at gmain.c line 3856
#26 g_main_context_iterate
at gmain.c line 3929
#27 g_main_loop_run
at gmain.c line 4125
#28 WTF::RunLoop::run()
at /usr/src/debug/webkitgtk-2.14.2/Source/WTF/wtf/glib/RunLoopGLib.cpp line 94
#29 WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**)
at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/Shared/unix/ChildProcessMain.h line 61
#30 __libc_start_main
#31 _start

Comment 5 Mark Tinberg 2016-12-05 15:51:11 UTC

(In reply to Milan Crha from comment #3)
> Thanks for a bug report. Looking at the WebKitWebProcess backtrace, its main
> thread is stuck in some threaded rendering, blocking all other requests.
> This looks like a valid issue in the WebKitGTK+ to me, but I do not know it
> enough.
> 
> Could you try to run evolution from a terminal like this:
> 
>    $ WEBKIT_DISABLE_COMPOSITING_MODE=1 evolution
> 
> to see whether it'll help, please?

I'm having the same problem, glad I could find the bug ticket, it was just happening for me again right now.  I closed and restarted evolution from a terminal with the environment variable specified.  I started happening for me when I upgraded to F25 and started using Wayland as the default GPU layer.

Comment 6 Milan Crha 2017-01-19 17:14:42 UTC

I'm closing this in favour of evolution 3.22.3, where had been added a fix for bug #774067 which sets this environment variable on start.