I'm trying to run foliate 2.0.0 (https://johnfactotum.github.io/foliate/) with webkit-gtk-2.28.0 (both from pkgsrc, on NetBSD/amd64). When I run this on an X server with GL support, it works. When I run this on an VNC X server (tigervnc) without GL support, I get a WebKitWebProcess core dump and the book is not displayed. The backtrace of WebKitWebProcess.core looks like this: (gdb) bt #0 glXGetVisualFromFBConfig (dpy=dpy@entry=0x76387d5fb000, fbconfig=fbconfig@entry=0x0) at /usr/xsrc/external/mit/MesaLib/dist/src/glx/glxcmds.c:1735 #1 0x000076387eda84f6 in WebCore::GLContextGLX::createWindowContext (window=window@entry=23068676, platformDisplay=..., sharingContext=sharingContext@entry=0x0) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:155 #2 0x000076387eda90dd in WebCore::GLContextGLX::createContext (window=window@entry=23068676, platformDisplay=...) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:284 #3 0x000076387ed78e77 in WebCore::GLContext::createContextForWindow (windowHandle=23068676, platformDisplay=<optimized out>) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WebCore/platform/graphics/GLContext.cpp:89 #4 0x000076387dd68b66 in WebKit::ThreadedCompositor::createGLContext (this=0x763812fd8b28) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:89 #5 0x000076387dd66018 in WTF::Function<void ()>::operator()() const (this=0x7638161a00b8) at /usr/include/g++/bits/unique_ptr.h:345 #6 WebKit::CompositingRunLoop::<lambda()>::operator() (__closure=0x7638161a00b0) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp:90 #7 WTF::Detail::CallableWrapper<WebKit::CompositingRunLoop::performTaskSync(WTF::Function<void()>&&)::<lambda()>, void>::call(void) ( this=0x7638161a00a8) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/DerivedSources/ForwardingHeaders/wtf/Function.h:52 #8 0x000076387bd4e535 in WTF::Function<void ()>::operator()() const (this=<synthetic pointer>) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WTF/wtf/Lock.h:84 #9 WTF::RunLoop::performWork (this=0x763816188000) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WTF/wtf/RunLoop.cpp:107 #10 0x000076387bd7e6f4 in WTF::RunLoop::<lambda(gpointer)>::operator() (__closure=0x0, userData=<optimized out>) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WTF/wtf/glib/RunLoopGLib.cpp:68 #11 WTF::RunLoop::<lambda(gpointer)>::_FUN(gpointer) () at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WTF/wtf/glib/RunLoopGLib.cpp:70 #12 0x0000763871254f75 in g_main_dispatch (context=0x763878359000) at ../glib/gmain.c:3293 #13 g_main_context_dispatch (context=context@entry=0x763878359000) at ../glib/gmain.c:3958 #14 0x00007638712552c1 in g_main_context_iterate (context=0x763878359000, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4031 #15 0x0000763871255699 in g_main_loop_run (loop=0x763878388000) at ../glib/gmain.c:4225 #16 0x000076387bd7f4a3 in WTF::RunLoop::run () at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #17 0x000076387bd4fdd0 in WTF::Function<void ()>::operator()() const (this=<synthetic pointer>) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WTF/wtf/Function.h:81 #18 WTF::Thread::entryPoint (newThreadContext=0x763816e5bf00) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WTF/wtf/Threading.cpp:148 #19 0x000076387bd80828 in WTF::wtfThreadEntryPoint (context=<optimized out>) at /scratch/www/webkit-gtk/work/webkitgtk-2.28.0/Source/WTF/wtf/posix/ThreadingPOSIX.cpp:200 #20 0x000076387840caf2 in pthread__create_tramp (cookie=0x7638783f3000) at /usr/src/lib/libpthread/pthread.c:587 #21 0x000076386b28fc70 in ?? () from /usr/lib/libc.so.12 #22 0x0000000000000000 in ?? () Please let me know if you think this bug is somewhere else; I reported it here because the core dump is from WebKitWebProcess.
That's expected. To run without OpenGL you have to disable the hardware acceleration, and WebKitGTK defaults to enable it (so it will crash if you don't have OpenGL and you don't disable the acceleration). You can disable that either by exporting the environment variable WEBKIT_DISABLE_COMPOSITING_MODE=1 before running your program or by disabling the hardware-acceleration-policy setting when constructing the webview. Check: https://webkitgtk.org/reference/webkit2gtk/stable/WebKitSettings.html#WebKitSettings--hardware-acceleration-policy Note that if you disable the acceleration some things like CSS 3D transforms may work incorrectly. For example you will see a flat animation here: https://webkit.org/blog-files/3d-transforms/poster-circle.html
Thank you for the links. The workaround you provide with setting WEBKIT_DISABLE_COMPOSITING_MODE=1 indeed avoids the coredump for me. Thank you! However, this leaves me with more questions :) Getting core dumps is not nice for users, and the setting is not easily guessable. So I assume applications should check more carefully before calling webkit-gtk, or set it up differently. Is there something I can tell the foliate developers to do to avoid the crash? As an example for a positive experience with webkit-gtk in the same environment: I have been using gnucash for many years, and gnucash embeds a HTML viewer using webkit-gtk. I have never had a crash in gnucash because of this problem.
(In reply to Thomas Klausner from comment #2) > Thank you for the links. > > The workaround you provide with setting WEBKIT_DISABLE_COMPOSITING_MODE=1 > indeed avoids the coredump for me. Thank you! > > However, this leaves me with more questions :) > > Getting core dumps is not nice for users, and the setting is not easily > guessable. So I assume applications should check more carefully before > calling webkit-gtk, or set it up differently. Is there something I can tell > the foliate developers to do to avoid the crash? > Honestly, this its's kind of a corner-case. As of 2020 everyone running a Desktop should have some way of running OpenGL content. Even in your example (VNC) you can have OpenGL on it. Maybe that its not easy on NetBSD (no idea), but at least on GNU/Linux its easy to do thanks to Xvfb/Mesa/llvmpipe. BTW, also note that WebKitGTK has an option to disable OpenGL at build-time. If you do that you not longer need to disable it at run-time (it will always default to disable the hardware-acceleration codepaths). > As an example for a positive experience with webkit-gtk in the same > environment: I have been using gnucash for many years, and gnucash embeds a > HTML viewer using webkit-gtk. I have never had a crash in gnucash because of > this problem. Well, I was wrong before when I said that WebKitGTK defaults to enable hardware-acceleration. In reality it just defaults to set it as "on-demand". That means that it will not trigger the hardware-acceleration paths until some web-content requires it (like for example some Web content trying to use CSS 3D transforms). So I suspect that GNUCash works without trouble for you because the Web content rendered by GNUCash its simple enough that it doesn't trigger any hadware-acelerated codepaths in WebKitGTK. But, on your other example (foliate) some web-content its liekly triggering this codepath, and that causes a crash when WebKitGTK tries to enter into the hardware-accelerated mode to better render this content (but your system doesn't allow it to call into OpenGL).