Bug 179304 – [GTK] Many webpages can crash the browser in WebCore::CoordinatedGraphicsLayer::transformedVisibleRect

• Component: WebKitGTK
• Status: RESOLVED FIXED

[antoyo]

Hello.
With the upgrade to webkit2gtk 2.18 (now using version 2.18.2), there are many webpages that can crash the web process (verified in Epiphany).
This webpage in particular will crash the web process in Epiphany:
https://www.harrypotterplatform934.com/pages/faqs

Just wait 30 seconds and scroll down a bit (I don't know what triggers the bug, but I always get the crash).

Thanks to fix this issue.

[Michael Catanzaro]

Hi, you need to post a backtrace when reporting crashes if you want us to investigate. That page works fine for me.

[antoyo]

Well, I can post it, but I don't have the debug symbols, so it's useless.
Here it is:

Thread 1 "WebKitWebProces" received signal SIGSEGV, Segmentation fault.
0x00007fbf0dc8f507 in ?? () from /usr/lib/libwebkit2gtk-4.0.so.37
(gdb) bt
#0  0x00007fbf0dc8f507 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#1  0x00007fbf0dc90eb6 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#2  0x00007fbf0dc90f26 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#3  0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#4  0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#5  0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#6  0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#7  0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#8  0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#9  0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#10 0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#11 0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#12 0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#13 0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#14 0x00007fbf0dc90f50 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#15 0x00007fbf0d0ce4b3 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#16 0x00007fbf0d0d3075 in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#17 0x00007fbf0d0d359b in  () at /usr/lib/libwebkit2gtk-4.0.so.37
#18 0x00007fbf09674b14 in WTF::RunLoop::performWork() () at /usr/lib/libjavascriptcoregtk-4.0.so.18
#19 0x00007fbf096ad3fa in  () at /usr/lib/libjavascriptcoregtk-4.0.so.18
#20 0x00007fbf09b6d0be in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#21 0x00007fbf09b6ef69 in  () at /usr/lib/libglib-2.0.so.0
#22 0x00007fbf09b6ff42 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#23 0x00007fbf096ade5a in WTF::RunLoop::run() () at /usr/lib/libjavascriptcoregtk-4.0.so.18
#24 0x00007fbf0d0dd0ab in WebProcessMainUnix () at /usr/lib/libwebkit2gtk-4.0.so.37
#25 0x00007fbf0c0b0f6a in __libc_start_main () at /usr/lib/libc.so.6
#26 0x000055d2159b689a in _start ()

[Michael Catanzaro]

You're right, it's useless. You'll obviously need to install debug symbols if you want us to be able to investigate the crash.

[Philippe Normand]

Hey Anthony, I can't reproduce this crash either here (2.18.2 and SVN trunk). When I start scrolling a subscribe banner appears on top of the page and always remains visible. Maybe that's what triggers the crash for you.

Can you report this downstream to the ArchLinux folks? It would be interesting to know if other ArchLinux users are also affected by this issue.

[Michael Catanzaro]

That's a waste of time; it's clearly a WebKit bug, not an Arch bug. But anyway, without a backtrace, there's nothing to do here, sorry.

[Philippe Normand]

(In reply to Michael Catanzaro from comment #5)
> That's a waste of time; it's clearly a WebKit bug, not an Arch bug.

Until proven otherwise, you don't know what it is. I didn't say it is an Arch bug.
I advised to report this downstream, which is different.

[Carlos Alberto Lopez Perez]

AFAIK there are mainly two things that can cause crashes on "many webpages"


1) Broken GPU drivers
Please try to start the browser with AC disabled, to do that export this variable before executing the browser from the terminal

export WEBKIT_DISABLE_COMPOSITING_MODE=1



2) JSC JIT on a not well supported platform

Are you maybe using a 32-bit platform? Try to disable the JIT at run-time by exporting this on a terminal before starting the browser:

export JavaScriptCoreUseJIT=0



Let us know if any of this two workarounds helps.

[Michael Catanzaro]

The crash is in /usr/lib/libwebkit2gtk-4.0.so.37... that does not prove, but strongly suggests that it's a WebKit bug. It would be extremely unusual for such a crash to not be a WebKit bug. (It also suggests that this is probably not a JIT bug, but no harm in trying that environment variable anyway.)

I can all but guarantee that the only response to a downstream bug report would be "please report upstream." On the Arch bugtracker specifically, but also on pretty much every other distribution's bugtracker. So I would not recommend reporting it anywhere else. The best path forward here would be to post a quality backtrace, then we can reopen the bug and maybe take a look.

[antoyo]

Here's the backtrace:

#0  0x00007f11dfb0d6d7 in WebCore::CoordinatedGraphicsLayer::transformedVisibleRect() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:890
#1  0x00007f11dfb0ed29 in WebCore::CoordinatedGraphicsLayer::updateContentBuffers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:968
#2  0x00007f11dfb0edb3 in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:940
#3  0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#4  0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#5  0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#6  0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#7  0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#8  0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#9  0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#10 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#11 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#12 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#13 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#14 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#15 0x00007f11df097507 in WebKit::CompositingCoordinator::flushPendingLayerChanges() ()
    at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CompositingCoordinator.cpp:123
#16 0x00007f11df09c0eb in WebKit::CoordinatedLayerTreeHost::layerFlushTimerFired() ()
    at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:204
#17 0x00007f11df09c2d8 in WebKit::CoordinatedLayerTreeHost::renderNextFrame() ()
    at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:178
#18 0x00007f11dc923550 in WTF::RunLoop::performWork() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#19 0x00007f11dc923550 in WTF::RunLoop::performWork() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/RunLoop.cpp:106
#20 0x00007f11dc94be09 in _FUN() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:68
#21 0x00007f11dc94be09 in _FUN() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:70
#22 0x00007f11d7e972da in g_main_context_dispatch (context=0x5eb800) at gmain.c:3148
#23 0x00007f11d7e972da in g_main_context_dispatch (context=context@entry=0x5eb800) at gmain.c:3813
#24 0x00007f11d7e97698 in g_main_context_iterate (context=0x5eb800, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3886
#25 0x00007f11d7e979c2 in g_main_loop_run (loop=0x83f6b0) at gmain.c:4082
#26 0x00007f11dc94c810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#27 0x00007f11df0a5859 in WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**) ()
    at /run/build-runtime/webkitgtk4/Source/WebKit/Shared/unix/ChildProcessMain.h:61
#28 0x0000003753a20291 in __libc_start_main (main=
    0x400bd0 <main()>, argc=2, argv=0x7ffeb27bb388, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffeb27bb378)
    at /usr/src/debug/glibc/2.24-r0/git/csu/libc-start.c:289
#29 0x0000000000400c5a in _start () at ../sysdeps/x86_64/start.S:120

[Michael Catanzaro]

Thanks.

Even better if you could get a backtrace with 'bt full'.

[Carlos Alberto Lopez Perez]

"thread apply all bt full" even better. Check: https://trac.webkit.org/wiki/WebKitGTK/Debugging#Gettingabacktracefromacoredump

[antoyo]

Here's the complete backtrace:

Thread 27 (Thread 0x7f50f244d700 (LWP 181)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50f418d700, timeout=<optimized out>, context=0x7f50f4003e30) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50f418d700
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x7f50f4003e30, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50f418d700
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50f4303c70) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#5  0x00007f516bf61784 in call() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44
#6  0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#7  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#9  0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#10 0x0000003754207404 in start_thread (arg=0x7f50f244d700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f50f244d700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139985638708992, -1270168254981307517, 140723383535518, 140723383535519, 139985638708992, 139985667780544, 1224574728515912579, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 26 (Thread 0x7f50d1dff700 (LWP 175)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50c4001330, timeout=<optimized out>, context=0x7f50c40008c0) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50c4001330
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x7f50c40008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50c4001330
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50c4001200) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#5  0x00007f516bf61784 in call() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44
#6  0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#7  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#9  0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#10 0x0000003754207404 in start_thread (arg=0x7f50d1dff700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f50d1dff700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139985095227136, -1270168254981307517, 140723383543806, 140723383543807, 0, 237624242240, 1224652597346730883, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 25 (Thread 0x7f50d43ff700 (LWP 166)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50cc001330, timeout=<optimized out>, context=0x7f50cc0008c0) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50cc001330
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x7f50cc0008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50cc001330
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50cc001200) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#5  0x00007f516bf61784 in call() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44
#6  0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#7  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#9  0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#10 0x0000003754207404 in start_thread (arg=0x7f50d43ff700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f50d43ff700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139985135073024, -1270168254981307517, 140723383543806, 140723383543807, 0, 237624242240, 1224658919538590595, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 24 (Thread 0x7f50f1c4c700 (LWP 130)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=2, fds=0x7f50e8001340, timeout=<optimized out>, context=0x7f50e8001200) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 2
        allocated_nfds = 2
        fds = 0x7f50e8001340
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x7f50e8001200, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 2
        allocated_nfds = 2
        fds = 0x7f50e8001340
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50e80010c0) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#5  0x00007f516bf61784 in call() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44
#6  0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#7  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#9  0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#10 0x0000003754207404 in start_thread (arg=0x7f50f1c4c700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f50f1c4c700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139985630316288, -1270168254981307517, 140723383543198, 140723383543199, 139985630316288, 139985667780944, 1224582427781661571, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 22 (Thread 0x7f510943b700 (LWP 119)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50e4001670, timeout=<optimized out>, context=0x7f50e40013b0) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50e4001670
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x7f50e40013b0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50e4001670
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50e4001540) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#5  0x00007f516bf61784 in call() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44
#6  0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#7  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#9  0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#10 0x0000003754207404 in start_thread (arg=0x7f510943b700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f510943b700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139986024511232, -1270168254981307517, 140723383543646, 140723383543647, 139986024511232, 18543392, 1224247051502257027, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 21 (Thread 0x7f50f144b700 (LWP 118)):
#0  0x000000375420d498 in pthread_cond_timedwait ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00007f516bf6136a in WTF::ThreadCondition::timedWait(WTF::Mutex&, double) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:587
#2  0x00007f516bf36c13 in WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ParkingLot.cpp:598
#3  0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ParkingLot.h:85
#4  0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Condition.h:81
#5  0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Condition.h:121
#6  0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/AutomaticThread.cpp:207
#7  0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#9  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#10 0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#11 0x0000003754207404 in start_thread (arg=0x7f50f144b700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f50f144b700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139985621923584, -1270168254981307517, 140723383542126, 140723383542127, 139985621923584, 139985667781344, 1224581328806904707, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#12 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 20 (Thread 0x7f50da7fc700 (LWP 113)):
#0  0x000000375420d498 in pthread_cond_timedwait ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00007f516bf6136a in WTF::ThreadCondition::timedWait(WTF::Mutex&, double) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:587
#2  0x00007f516bf36c13 in WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ParkingLot.cpp:598
#3  0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ParkingLot.h:85
#4  0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Condition.h:81
#5  0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Condition.h:121
#6  0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/AutomaticThread.cpp:207
#7  0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#9  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#10 0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#11 0x0000003754207404 in start_thread (arg=0x7f50da7fc700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f50da7fc700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139985239918336, -1270168254981307517, 140723383542670, 140723383542671, 0, 237624242240, 1224627585067811715, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#12 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 11 (Thread 0x7f50f3fff700 (LWP 43)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=2, fds=0x7f50ec001330, timeout=<optimized out>, context=0x7f50ec0008c0) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 2
        allocated_nfds = 2
        fds = 0x7f50ec001330
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x7f50ec0008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 2
        allocated_nfds = 2
        fds = 0x7f50ec001330
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50ec001200) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#5  0x00007f516bf61784 in call() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44
#6  0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#7  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#9  0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#10 0x0000003754207404 in start_thread (arg=0x7f50f3fff700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f50f3fff700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139985667749632, -1270168254981307517, 140723383548190, 140723383548191, 0, 237624242240, 1224578105433949059, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 10 (Thread 0x7f5108c3a700 (LWP 40)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50f80010c0, timeout=<optimized out>, context=0x11a6320) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50f80010c0
#2  0x00007f51674ad626 in g_main_context_iterate (context=context@entry=0x11a6320, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50f80010c0
#3  0x00007f51674ad74c in g_main_context_iteration (context=context@entry=0x11a6320, may_block=may_block@entry=1)
    at gmain.c:3947
        retval = <optimized out>
#4  0x00007f5158d3f0cd in dconf_gdbus_worker_thread (user_data=0x11a6320) at dconf-gdbus-thread.c:82
        context = 0x11a6320
#5  0x00007f51674d54f5 in g_thread_proxy (data=0x11cda80) at gthread.c:784
        thread = 0x11cda80
#6  0x0000003754207404 in start_thread (arg=0x7f5108c3a700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f5108c3a700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139986016118528, -1270168254981307517, 140723383546942, 140723383546943, 0, 237624242240, 1224245950380016515, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#7  0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 8 (Thread 0x7f510affb700 (LWP 38)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=2, fds=0x7f5100001730, timeout=<optimized out>, context=0x7f51000008c0) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 2
        allocated_nfds = 2
        fds = 0x7f5100001730
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x7f51000008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 2
        allocated_nfds = 2
        fds = 0x7f5100001730
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f5100001600) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#5  0x00007f516bf61784 in call() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44
#6  0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#7  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#9  0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#10 0x0000003754207404 in start_thread (arg=0x7f510affb700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f510affb700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139986053609216, -1270168254981307517, 140723383549646, 140723383549647, 0, 237624242240, 1224241657023333251, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 7 (Thread 0x7f510b7fc700 (LWP 37)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50fc001730, timeout=<optimized out>, context=0x7f50fc0008c0) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50fc001730
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x7f50fc0008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f50fc001730
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50fc001600) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#5  0x00007f516bf61784 in call() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44
#6  0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#7  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#9  0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#10 0x0000003754207404 in start_thread (arg=0x7f510b7fc700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f510b7fc700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139986062001920, -1270168254981307517, 140723383549582, 140723383549583, 0, 237624242240, 1224242755998090115, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 6 (Thread 0x7f510bffd700 (LWP 36)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f5104001730, timeout=<optimized out>, context=0x7f51040008c0) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f5104001730
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x7f51040008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f5104001730
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f5104001600) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#5  0x00007f516bf61784 in call() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44
#6  0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#7  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#9  0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#10 0x0000003754207404 in start_thread (arg=0x7f510bffd700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f510bffd700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139986070394624, -1270168254981307517, 140723383549582, 140723383549583, 0, 237624242240, 1224243852825363331, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 5 (Thread 0x7f5158cd5700 (LWP 35)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f5150001330, timeout=<optimized out>, context=0x7f51500008c0) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f5150001330
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x7f51500008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f5150001330
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f5150001200) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#5  0x00007f516bf61784 in call() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44
#6  0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101
#7  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#8  0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129
#9  0x00007f516bf60859 in wtfThreadEntryPoint() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228
#10 0x0000003754207404 in start_thread (arg=0x7f5158cd5700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f5158cd5700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139987358930688, -1270168254981307517, 140723383549582, 140723383549583, 0, 237624242240, 1224351454641030019, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 4 (Thread 0x7f5159745700 (LWP 32)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=3, fds=0x7f514c0010c0, timeout=<optimized out>, context=0x1073070) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 3
        allocated_nfds = 3
        fds = 0x7f514c0010c0
#2  0x00007f51674ad626 in g_main_context_iterate (context=0x1073070, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 3
        allocated_nfds = 3
        fds = 0x7f514c0010c0
#3  0x00007f51674ad9c2 in g_main_loop_run (loop=0x107d800) at gmain.c:4082
        __func__ = "g_main_loop_run"
#4  0x00007f5167a96896 in gdbus_shared_thread_func (user_data=0x107d750) at gdbusprivate.c:275
        data = 0x107d750
#5  0x00007f51674d54f5 in g_thread_proxy (data=0x102db70) at gthread.c:784
        thread = 0x102db70
#6  0x0000003754207404 in start_thread (arg=0x7f5159745700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f5159745700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139987369875200, -1270168254981307517, 140723383545550, 140723383545551, 0, 237624242240, 1224352768901022595, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#7  0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 3 (Thread 0x7f5159f46700 (LWP 31)):
#0  0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f51540008e0, timeout=<optimized out>, context=0x10707f0) at gmain.c:4187
        ret = <optimized out>
        errsv = <optimized out>
        poll_func = 0x7f51674bd360 <g_poll>
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f51540008e0
#2  0x00007f51674ad626 in g_main_context_iterate (context=context@entry=0x10707f0, block=block@entry=1, dispatch=d
ispatch@entry=1, self=<optimized out>) at gmain.c:3881
        max_priority = 2147483647
        timeout = -1
        some_ready = <optimized out>
        nfds = 1
        allocated_nfds = 1
        fds = 0x7f51540008e0
#3  0x00007f51674ad74c in g_main_context_iteration (context=0x10707f0, may_block=may_block@entry=1)
    at gmain.c:3947
        retval = <optimized out>
#4  0x00007f51674ad791 in glib_worker_main (data=<optimized out>) at gmain.c:5742
#5  0x00007f51674d54f5 in g_thread_proxy (data=0x102dad0) at gthread.c:784
        thread = 0x102dad0
#6  0x0000003754207404 in start_thread (arg=0x7f5159f46700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f5159f46700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139987378267904, -1270168254981307517, 140723383545134, 140723383545135, 0, 237624242240, 1224353867875779459, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#7  0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 2 (Thread 0x7f515c155700 (LWP 22)):
#0  0x000000375420d498 in pthread_cond_timedwait ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() ()
    at /usr/include/c++/6.2.0/x86_64-unknown-linux/bits/gthr-default.h:871
#2  0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/condition_variable:166
#3  0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/condition_variable:106
#4  0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/condition_variable:274
#5  0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/condition_variable:285
#6  0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/condition_variable:300
#7  0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() ()
    at /run/build-runtime/webkitgtk4/Source/bmalloc/bmalloc/Scavenger.cpp:149
#8  0x00007f516329ff6f in std::execute_native_thread_routine(void*) (__p=0xfde390)
    at ../../../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libstdc++-v3/src/c++11/thread.cc:83
        __t = 
                {_M_t = {<std::_Tuple_impl<0ul, std::thread::_State*, std::default_delete<std::thread::_State> >> = {<std::_Tuple_impl<1ul, std::default_delete<std::thread::_State> >> = {<std::_Head_base<1ul, std::default_delete<std::thread::_State>, true>> = {<std::default_delete<std::thread::_State>> = {<No data fields>}, <No data fields>}, <No data fields>}, <std::_Head_base<0ul, std::thread::_State*, false>> = {_M_head_impl = 0xfde390}, <No data fields>}, <No data fields>}}
#9  0x0000003754207404 in start_thread (arg=0x7f515c155700)
    at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456
        __res = <optimized out>
        pd = 0x7f515c155700
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139987413980928, -1270168254981307517, 140723383549934, 1407233835499
35, 0, 237624242240, 1224359632258761603, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#10 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 1 (Thread 0x7f515c159900 (LWP 21)):
#0  0x00007f516f1236d7 in WebCore::CoordinatedGraphicsLayer::transformedVisibleRect() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:890
#1  0x00007f516f124d29 in WebCore::CoordinatedGraphicsLayer::updateContentBuffers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:968
#2  0x00007f516f124db3 in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:940
#3  0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#4  0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#5  0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#6  0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#7  0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#8  0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#9  0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#10 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#11 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#12 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#13 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#14 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() ()
    at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943
#15 0x00007f516e6ad507 in WebKit::CompositingCoordinator::flushPendingLayerChanges() ()
    at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CompositingCoordinator.cpp:123
#16 0x00007f516e6b20eb in WebKit::CoordinatedLayerTreeHost::layerFlushTimerFired() ()
    at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:204
#17 0x00007f516e6b22d8 in WebKit::CoordinatedLayerTreeHost::renderNextFrame() ()
    at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:178
#18 0x00007f516bf39550 in WTF::RunLoop::performWork() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56
#19 0x00007f516bf39550 in WTF::RunLoop::performWork() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/RunLoop.cpp:106
#20 0x00007f516bf61e09 in _FUN() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:68
#21 0x00007f516bf61e09 in _FUN() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:70
#22 0x00007f51674ad2da in g_main_context_dispatch (context=0x104c8f0) at gmain.c:3148
        dispatch = 0x7f516bf61e20 <_FUN()>
        prev_source = 0x0
        was_in_call = 0
        user_data = 0x7f515b8f9000
        callback = 0x7f516bf61e00 <_FUN()>
        cb_funcs = <optimized out>
        cb_data = 0x11bc2e0
        need_destroy = <optimized out>
        source = 0x11bc250
        current = 0x107af50
        i = 0
#23 0x00007f51674ad2da in g_main_context_dispatch (context=context@entry=0x104c8f0) at gmain.c:3813
#24 0x00007f51674ad698 in g_main_context_iterate (context=0x104c8f0, block=block@entry=1, dispatch=dispatch@entry=
1, self=<optimized out>) at gmain.c:3886
        max_priority = 100
        timeout = 0
        some_ready = 1
        nfds = 4
        allocated_nfds = 4
        fds = <optimized out>
#25 0x00007f51674ad9c2 in g_main_loop_run (loop=0x11bc230) at gmain.c:4082
        __func__ = "g_main_loop_run"
#26 0x00007f516bf62810 in WTF::RunLoop::run() ()
    at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96
#27 0x00007f516e6bb859 in WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**) ()
    at /run/build-runtime/webkitgtk4/Source/WebKit/Shared/unix/ChildProcessMain.h:61
#28 0x0000003753a20291 in __libc_start_main (main=
    0x400bd0 <main()>, argc=2, argv=0x7ffcb749c2b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcb749c2a8) at /usr/src/debug/glibc/2.24-r0/git/csu/libc-start.c:289
        result = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {0, -1270168804309302397, 4197424, 140723383550640, 0, 0, 1271732670176199555, -1283011358323997821}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7ffcb749c2d0, 0x3753824168}, data = {prev = 0x0, cleanup = 0x0, canceltype = -1219902768}}}
        not_first_call = <optimized out>
#29 0x0000000000400c5a in _start () at ../sysdeps/x86_64/start.S:120

[Jan Burgmeier]

Hi,

I'm also affected by this bug on a 32bit platform with webkit2gtk 2.18.3 and can confirm that disabling jit solves the problem for me.

[Michael Catanzaro]

Created attachment 336663 [details]
Better backtrace

Here's a better backtrace

We have 291 reports of this in Fedora.

[Jan Burgmeier]

Hi,

for me the problem was, that I build a i686 webkit2gtk in a chroot on a x86_64 system and I did not use "setarch i686" to run commands in the chroot. This was the reason for cmake to think it was building on x86_64 and set CMAKE_HOST_SYSTEM to x86_64.
The build worked fine and the resulted webkit2gtk worked but it crashed WebCore::CoordinatedGraphicsLayer::transformedVisibleRect when it was run without WEBKIT_DISABLE_COMPOSITING_MODE=1.
After building with "setarch i686" I had no problems.

[Carlos Bentzen]

Hey mcatanzaro, can you post the downstream Fedora bug report here? If there are other webpages mentioned there that can crash the browser it would be helpful for me to try to isolate the crash situation in a test.

[Carlos Bentzen]

The crash happens basically because m_coordinator is null at 

FloatRect rect = m_cachedInverseTransform.clampedBoundsOfProjectedQuad(FloatQuad(m_coordinator->visibleContentsRect()));

And it happens after AC goes through on -> off -> on. 

> Just wait 30 seconds and scroll down a bit (I don't know what triggers the bug, but I always get the crash).

We have to wait a few seconds because there is a 5s timer to free the resources when turning AC off. 

When AC is turned off, all CoordinatedGraphicsLayers should be destroyed, I believe. However in this page some layers are not destroyed and left with a null m_coordinator, which happens in CompositingCoordinator destructor:

for (auto& registeredLayer : m_registeredLayers.values())
    registeredLayer->setCoordinator(nullptr);

Then, when AC is on again, those same layers are reused with m_coordinator == nullptr and results in the crash.

> https://www.harrypotterplatform934.com/pages/faqs

In this page in specific, the node that causes the crash is a div inside of an iframe that has css animation on translateY property (which is what triggers AC on I guess). The iframe has 0px width and 0px height though so it does not show on the screen and I'm not sure GraphicsLayers should be created for it in this case. This page however is quite big and the CSS properties are maybe changed via JS. So other pages would help understand this more easily.

[Michael Catanzaro]

(In reply to Carlos Eduardo Ramalho from comment #16)
> Hey mcatanzaro, can you post the downstream Fedora bug report here? If there
> are other webpages mentioned there that can crash the browser it would be
> helpful for me to try to isolate the crash situation in a test.

I can post the backtraces, but there's no way to know what websites triggered them.

(In reply to Carlos Eduardo Ramalho from comment #17)
> The crash happens basically because m_coordinator is null

Hmmm, I think Miguel was looking into a different bug where this was confusing him. Maybe it's the same underlying issue. Would be good to check with him.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #18)
> I can post the backtraces, but there's no way to know what websites
> triggered them.

Actually the first backtrace is already attached, and the second one is not worth posting as gdb hung.

[Carlos Bentzen]

> I can post the backtraces, but there's no way to know what websites
> triggered them.

Ahh ok. I thought people reported it downstream in fedora bugzilla with links but it's just crash reports from fedora. Sorry for my confusion.

Thanks anyway :)

[Carlos Bentzen]

Created attachment 338322 [details]
Dump of Graphics Layers

Dump of the Graphics Layers right before crashing.

Notice I added the "coordinator" field and it shows that all iframe children have a null coordinator.

[Michael Catanzaro]

Created attachment 338326 [details]
Backtrace

Another backtrace, in case it helps

We're up to 322 reports of this in Fedora (not too many), first occurrence was 2017-06-26

[Carlos Bentzen]

(In reply to Carlos Eduardo Ramalho from comment #17) 
> We have to wait a few seconds because there is a 5s timer to free the
> resources when turning AC off. 

I was wrong in that statement. Actually we have to wait usually 13s to reproduce the crash on https://www.harrypotterplatform934.com/pages/faqs because AC is turned on every 6.5s: the JS script defines this time to make a transition a slide div (slidesjs-control) that shows up on the left side of the page below the menu.

This animated transition (using translateX) triggers AC off -> on -> off every 6.5s.

So the scenario is like that:
0s    -> page opens
6.5   -> slidejs animation: AC off -> on -> off
11.5s -> 5s timer kicks in, discarding previous LayerTreeHost
13s   -> slidejs animation: AC off -> on, then segfault in CoordinatedGraphicsLayer::transformedVisibleRect()


The GraphicsLayer node that causes the crash is in a div with animation embedded in a iframe, this iframe is inserted to the DOM via JS. However there's some catch I didn't figure out yet because doing so in the same scenario in a simpler webpage does not cause the crash.

[Miguel Gomez]

As Carlos mentions, the problem is the null compositor on some of the layers. When leaving AC, all the GraphicsLayers are destroyed except the children of the iframe containing the dialog (see the attached GraphicsLayer dump). But 5 seconds after that, the CompositingCoordinator is destroyed, setting compositor attribute to null for those layers.

When scrolling the page, seems that the iframe with the dialog is added to the page again, and that causes that the surviving GraphicsLayers are added again to the GraphicsLayer tree, but their coordinator is not properly set, so the crash during the layer flush happens.

I need to investigate why these GraphicsLayers are kept alive, and if it makes sense to do that, or we should be destroying them. Maybe it's an optimization speed up the rendering of constant subtrees (in which case we should just the appropriate coordinator when reattaching the subtree) or maybe it's a bug and we should just destroy them and recreate them when needed.

[Miguel Gomez]

Created attachment 342736 [details]
Patch

[Zan Dobersek]

Comment on attachment 342736 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=342736&action=review

> Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
> +    // If the coordinators are different it means that we are attaching a layer that was created by a different
> +    // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree
> +    // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the
> +    // layer and its children.

The dynamic AC entry and exit continues to produce bugs and require fixes that only complicate the CoordinatedGraphics stack and any future improvements. I propose WebKitGTK+ adds an API that for the specific UIProcess instance either enables or disables AC, but otherwise abandons dynamic AC entry and exit.

[Miguel Gomez]

> The dynamic AC entry and exit continues to produce bugs and require fixes
> that only complicate the CoordinatedGraphics stack and any future
> improvements. I propose WebKitGTK+ adds an API that for the specific
> UIProcess instance either enables or disables AC, but otherwise abandons
> dynamic AC entry and exit.

That would indeed simplify things, but last time we tried that we had all those excessive memory consumption problems.

I think we have improved a bit since that, but still there's going to be a noticeable difference in memory usage if AC is always enabled. Anyway, we can take some measures and see.

[Miguel Gomez]

(In reply to Miguel Gomez from comment #27)
> > The dynamic AC entry and exit continues to produce bugs and require fixes
> > that only complicate the CoordinatedGraphics stack and any future
> > improvements. I propose WebKitGTK+ adds an API that for the specific
> > UIProcess instance either enables or disables AC, but otherwise abandons
> > dynamic AC entry and exit.
> 
> That would indeed simplify things, but last time we tried that we had all
> those excessive memory consumption problems.
> 
> I think we have improved a bit since that, but still there's going to be a
> noticeable difference in memory usage if AC is always enabled. Anyway, we
> can take some measures and see.

Fast memory usage test:

* about::blank non AC 1920x0180: 86848KB
* about::blank AC 1920x0180: 102396KB
* webkitgtk.org non AC: 104172KB
* webkitgtk.org AC: 128420KB

about ~20MB increased memory.

Anyway this gap will be reduced if we can get rid of the cairo rasterization.

[Zan Dobersek]

(In reply to Miguel Gomez from comment #28)
> (In reply to Miguel Gomez from comment #27)
> > > The dynamic AC entry and exit continues to produce bugs and require fixes
> > > that only complicate the CoordinatedGraphics stack and any future
> > > improvements. I propose WebKitGTK+ adds an API that for the specific
> > > UIProcess instance either enables or disables AC, but otherwise abandons
> > > dynamic AC entry and exit.
> > 
> > That would indeed simplify things, but last time we tried that we had all
> > those excessive memory consumption problems.
> > 
> > I think we have improved a bit since that, but still there's going to be a
> > noticeable difference in memory usage if AC is always enabled. Anyway, we
> > can take some measures and see.
> 
> Fast memory usage test:
> 
> * about::blank non AC 1920x0180: 86848KB
> * about::blank AC 1920x0180: 102396KB
> * webkitgtk.org non AC: 104172KB
> * webkitgtk.org AC: 128420KB
> 
> about ~20MB increased memory.
> 
> Anyway this gap will be reduced if we can get rid of the cairo rasterization.

Regardless of how Cairo replacement goes, I'll still move over WPE to a separate LayerTreeHost and GraphicsLayer tree implementation if future changes to CoordinatedGraphics that are addressing AC dynamic entry-exit issues conflict with other improvements.

[Zan Dobersek]

Comment on attachment 342736 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=342736&action=review

> Source/WebCore/ChangeLog:10
> +        When adding new CoordinatedGraphicsLayers to the tree, check that they have the appropriate
> +        CompositingCoordinator. If that's not the case, set the appropriate one to the layer and its
> +        children and set the state of those layers so they are rendered properly.

Is there a case where layers created via (already-destroyed) CompositingCoordinator#1 are added to a layer tree managed by CompositingCoordinator#2 *that are not* the root compositing layer or the view overlay layer that are set via CompositingCoordinator::setRootCompositingLayer() or CompositingCoordinator::setViewOverlayRootLayer()?

[Carlos Garcia Campos]

(In reply to Zan Dobersek from comment #26)
> Comment on attachment 342736 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=342736&action=review
> 
> > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
> > +    // If the coordinators are different it means that we are attaching a layer that was created by a different
> > +    // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree
> > +    // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the
> > +    // layer and its children.
> 
> The dynamic AC entry and exit continues to produce bugs and require fixes
> that only complicate the CoordinatedGraphics stack and any future
> improvements. I propose WebKitGTK+ adds an API that for the specific
> UIProcess instance either enables or disables AC, but otherwise abandons
> dynamic AC entry and exit.

It's actually revealing existing bugs in most of the cases I would say. But still, we are not going to change it. I don't think cairo is the problem either. I think we would need to move the threaded compositor to the UI process to be able to get rid of the non accelerated rendering mode. Note that we already have API to force compositing, disable it or keep it on demand (the default). Note also that this problem is not specific to GTK+, the same happens in WPE, the difference is that WPE is not used by general purpose browsers with tons of tabs opened.

[Zan Dobersek]

Comment on attachment 342736 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=342736&action=review

>>> Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
>>> +    // layer and its children.
>> 
>> The dynamic AC entry and exit continues to produce bugs and require fixes that only complicate the CoordinatedGraphics stack and any future improvements. I propose WebKitGTK+ adds an API that for the specific UIProcess instance either enables or disables AC, but otherwise abandons dynamic AC entry and exit.
> 
> It's actually revealing existing bugs in most of the cases I would say. But still, we are not going to change it. I don't think cairo is the problem either. I think we would need to move the threaded compositor to the UI process to be able to get rid of the non accelerated rendering mode. Note that we already have API to force compositing, disable it or keep it on demand (the default). Note also that this problem is not specific to GTK+, the same happens in WPE, the difference is that WPE is not used by general purpose browsers with tons of tabs opened.

WPE always remains in AC mode, it doesn't enter and exit it depending on the content. GraphicsLayer objects don't get transferred from one CompositingCoordinator to another. So no, this doesn't affect WPE.

[Carlos Garcia Campos]

(In reply to Zan Dobersek from comment #32)
> Comment on attachment 342736 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=342736&action=review
> 
> >>> Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
> >>> +    // layer and its children.
> >> 
> >> The dynamic AC entry and exit continues to produce bugs and require fixes that only complicate the CoordinatedGraphics stack and any future improvements. I propose WebKitGTK+ adds an API that for the specific UIProcess instance either enables or disables AC, but otherwise abandons dynamic AC entry and exit.
> > 
> > It's actually revealing existing bugs in most of the cases I would say. But still, we are not going to change it. I don't think cairo is the problem either. I think we would need to move the threaded compositor to the UI process to be able to get rid of the non accelerated rendering mode. Note that we already have API to force compositing, disable it or keep it on demand (the default). Note also that this problem is not specific to GTK+, the same happens in WPE, the difference is that WPE is not used by general purpose browsers with tons of tabs opened.
> 
> WPE always remains in AC mode, it doesn't enter and exit it depending on the
> content. GraphicsLayer objects don't get transferred from one
> CompositingCoordinator to another. So no, this doesn't affect WPE.

What I meant is that the memory and performance problem of being always in AC mode si not specific to GTK+, it affects WPE as well. But it's very noticeable in WebKitGTK+ because it's used in general purpose browsers with a lot of tabs opened. That requires a lot of memory because we have one gl context per tab. And it's not only the browser startup performance, but every time you open a new tab,  a new gl context is created making the tab creation slow.

[Zan Dobersek]

(In reply to Carlos Garcia Campos from comment #31)
> (In reply to Zan Dobersek from comment #26)
> > Comment on attachment 342736 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=342736&action=review
> > 
> > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
> > > +    // If the coordinators are different it means that we are attaching a layer that was created by a different
> > > +    // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree
> > > +    // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the
> > > +    // layer and its children.
> > 
> > The dynamic AC entry and exit continues to produce bugs and require fixes
> > that only complicate the CoordinatedGraphics stack and any future
> > improvements. I propose WebKitGTK+ adds an API that for the specific
> > UIProcess instance either enables or disables AC, but otherwise abandons
> > dynamic AC entry and exit.
> 
> It's actually revealing existing bugs in most of the cases I would say. But
> still, we are not going to change it.

This will certainly block async scrolling for the GTK+ port, because of how the scrolling is handled. It might also collide with other improvements in composition.

> I don't think cairo is the problem either.

It certainly is. Whenever anything is drawn, with Cairo, a backing store has to be used. This means rasterizing into CPU memory that then gets copied over to the GPU. So you need to first waste the CPU memory to get all the backing stores updated, before you waste the GPU memory to hold all the backing store content there.

Only improvement possible is leveraging mapping of GPU memory into user-space and rasterizing with Cairo into that area. The largest problem then is management of these memory areas, but I can assure you that handling regularly-occurring AC entries and exits will not help one bit.

> I think we would need to move the threaded compositor to the UI
> process to be able to get rid of the non accelerated rendering mode.

This in no way improves the backing store memory consumption problem, as described above. If your argument is that OpenGL-and-GLX combo is still too heavy to initialize in every WebProcess, we should be looking into adopting EGL and OpenGL ES universally.

But even then, with lots of tabs open, the large majority of memory is not spent on the graphics pipeline, but other things like Web content and caches. You should be looking into WebProcess management instead.

> Note
> that we already have API to force compositing, disable it or keep it on
> demand (the default). Note also that this problem is not specific to GTK+,
> the same happens in WPE, the difference is that WPE is not used by general
> purpose browsers with tons of tabs opened.

Explained in the previous comment.

[Michael Catanzaro]

In addition to the need to fix the memory usage problem, switching to OpenGL makes us responsible for bugs like bug #170347, which is still unfixed. Unless our graphics experts are able to successfully debug and resolve such issues on hardware we do not own, in a reasonable amount of time after bugs are reported, then I don't see any hope of switching to GPU rendering. If we switch to always-on AC mode, there will be a multitude of new such issues reported. If we're not able to handle them, then we'll just need to switch back. I don't want to veto this or anything, just point out that if we do it, it will mean increased work debugging hardware-specific issues will be required from our graphics experts, and I'm not sure if we're prepared for that.

And, as we discussed in the past, always-on AC is almost certainly going to require a GPU blacklist, but I guess we don't need one until we have a bug report and want to add the first GPU to it.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #35)
> In addition to the need to fix the memory usage problem, switching to OpenGL
> makes us responsible for bugs like bug #170347,

Also bug #180739, also unfixed

[Carlos Alberto Lopez Perez]

(In reply to Carlos Garcia Campos from comment #33)
> [...]
> I think we would need to move the threaded compositor to the UI process to be able to get rid of the non accelerated rendering mode. 

That would mean exposing the UIProcess to crashes if the OpenGL drivers don't behave correctly, right?

Crashing the WebProces is bad, but crashing the UIProcess is much worse... the app can't recover itself without external help.

> > 
> > WPE always remains in AC mode, it doesn't enter and exit it depending on the
> > content. GraphicsLayer objects don't get transferred from one
> > CompositingCoordinator to another. So no, this doesn't affect WPE.
> 
> What I meant is that the memory and performance problem of being always in
> AC mode si not specific to GTK+, it affects WPE as well. But it's very
> noticeable in WebKitGTK+ because it's used in general purpose browsers with
> a lot of tabs opened. That requires a lot of memory because we have one gl
> context per tab. And it's not only the browser startup performance, but
> every time you open a new tab,  a new gl context is created making the tab
> creation slow.


I guess the ideal solution would be to have a GPURenderProcess where the same gl context is shared for all the WebProcess/tabs.

[Carlos Bentzen]

As a side note, when I was investigating this bug I stabbed upon this bit in RenderLayerCompositor::computeCompositingRequirements():

// If we're back at the root, and no other layers need to be composited, and the root layer itself doesn't need
// to be composited, then we can drop out of compositing mode altogether. However, don't drop out of compositing mode
// if there are composited layers that we didn't hit in our traversal (e.g. because of visibility:hidden).
if (layer.isRenderViewLayer() && !childState.subtreeIsCompositing && !requiresCompositingLayer(layer) && !m_forceCompositingMode && !hasAnyAdditionalCompositedLayers(layer)) {
    // Don't drop out of compositing on iOS, because we may flash. See <rdar://problem/8348337>.
#if !PLATFORM(IOS)
    enableCompositingMode(false);
    willBeComposited = false;
#endif
}

Adding GTK the the #if 'fixed' this bug because once the WebProcess entered AC mode, it would not leave anymore.

I didn't consider submitting this as I thought it was not in the plans to do something like that and a proper fix like the one Miguel sent would be the correct approach.

However, now that this discussion has come up it might be relevant... If I'm correct, doing this would still render non-AC pages if no acceleration is required, but pages that do require (even temporarily) would stay in AC mode afterwards.

That would avoid special logic for dynamic on-off AC mode, since the only AC mode-switching would be OFF -> ON once if required. I may be totally wrong here though, if so do correct me.

[Miguel Gomez]

(In reply to Zan Dobersek from comment #30)
> Comment on attachment 342736 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=342736&action=review
> 
> > Source/WebCore/ChangeLog:10
> > +        When adding new CoordinatedGraphicsLayers to the tree, check that they have the appropriate
> > +        CompositingCoordinator. If that's not the case, set the appropriate one to the layer and its
> > +        children and set the state of those layers so they are rendered properly.
> 
> Is there a case where layers created via (already-destroyed)
> CompositingCoordinator#1 are added to a layer tree managed by
> CompositingCoordinator#2 *that are not* the root compositing layer or the
> view overlay layer that are set via
> CompositingCoordinator::setRootCompositingLayer() or
> CompositingCoordinator::setViewOverlayRootLayer()?

From the tests I've been running, this problem is only reproducible with iframes (due to their own RenderLayerCompositor), and in those cases the root node of the layer subtree added to the new compositor is always the "overflow controls host" layer.

[Carlos Garcia Campos]

(In reply to Zan Dobersek from comment #34)
> (In reply to Carlos Garcia Campos from comment #31)
> > (In reply to Zan Dobersek from comment #26)
> > > Comment on attachment 342736 [details]
> > > Patch
> > > 
> > > View in context:
> > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review
> > > 
> > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
> > > > +    // If the coordinators are different it means that we are attaching a layer that was created by a different
> > > > +    // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree
> > > > +    // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the
> > > > +    // layer and its children.
> > > 
> > > The dynamic AC entry and exit continues to produce bugs and require fixes
> > > that only complicate the CoordinatedGraphics stack and any future
> > > improvements. I propose WebKitGTK+ adds an API that for the specific
> > > UIProcess instance either enables or disables AC, but otherwise abandons
> > > dynamic AC entry and exit.
> > 
> > It's actually revealing existing bugs in most of the cases I would say. But
> > still, we are not going to change it.
> 
> This will certainly block async scrolling for the GTK+ port, because of how
> the scrolling is handled. It might also collide with other improvements in
> composition.

Can't those be used only when in AC mode?

> > I don't think cairo is the problem either.
> 
> It certainly is. Whenever anything is drawn, with Cairo, a backing store has
> to be used. This means rasterizing into CPU memory that then gets copied
> over to the GPU. So you need to first waste the CPU memory to get all the
> backing stores updated, before you waste the GPU memory to hold all the
> backing store content there.
> 
> Only improvement possible is leveraging mapping of GPU memory into
> user-space and rasterizing with Cairo into that area. The largest problem
> then is management of these memory areas, but I can assure you that handling
> regularly-occurring AC entries and exits will not help one bit.

With exactly the same cairo code epiphany was unusable for most of the users when we switched to always use AC, and became usable again when we added the on demand mode. This is a fact. I would love to switch to always AC, and remove all the complexity of switching between modes, but we simply can't, at least not right now.

> > I think we would need to move the threaded compositor to the UI
> > process to be able to get rid of the non accelerated rendering mode.
> 
> This in no way improves the backing store memory consumption problem, as
> described above. If your argument is that OpenGL-and-GLX combo is still too
> heavy to initialize in every WebProcess, we should be looking into adopting
> EGL and OpenGL ES universally.

The problem was not specific to GLX, it happened exactly the same in wayland using EGL. The problem is quite simple, every gl context requires quite a bit of memory and creating the context also takes some time. When you only have one web view that's not a problem, the browser might be a bit slower once at startup and the gl context only adds some more memory. But when you open epiphany (or any other WebKitGTK+ based browser) with AC always enabled, the memory required for all the gl contexts is too much for most of the users. And every time you open a tab you notice the slowdown. Moving the compositing to the UI (or to a dedicated process as Carlos suggested) would use one gl context no matter how many tabs you have, fixing the problem.

> But even then, with lots of tabs open, the large majority of memory is not
> spent on the graphics pipeline, but other things like Web content and
> caches. You should be looking into WebProcess management instead.

If we fix all those problems with cairo and WebKitGTK+ browsers are usable with AC always enabled I'm open to try again, but that's not the case right now, with our current code the amount of memory gl adds on top makes it impossible.

> > Note
> > that we already have API to force compositing, disable it or keep it on
> > demand (the default). Note also that this problem is not specific to GTK+,
> > the same happens in WPE, the difference is that WPE is not used by general
> > purpose browsers with tons of tabs opened.
> 
> Explained in the previous comment.

[Zan Dobersek]

(In reply to Carlos Garcia Campos from comment #40)
> (In reply to Zan Dobersek from comment #34)
> > (In reply to Carlos Garcia Campos from comment #31)
> > > (In reply to Zan Dobersek from comment #26)
> > > > Comment on attachment 342736 [details]
> > > > Patch
> > > > 
> > > > View in context:
> > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review
> > > > 
> > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
> > > > > +    // If the coordinators are different it means that we are attaching a layer that was created by a different
> > > > > +    // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree
> > > > > +    // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the
> > > > > +    // layer and its children.
> > > > 
> > > > The dynamic AC entry and exit continues to produce bugs and require fixes
> > > > that only complicate the CoordinatedGraphics stack and any future
> > > > improvements. I propose WebKitGTK+ adds an API that for the specific
> > > > UIProcess instance either enables or disables AC, but otherwise abandons
> > > > dynamic AC entry and exit.
> > > 
> > > It's actually revealing existing bugs in most of the cases I would say. But
> > > still, we are not going to change it.
> > 
> > This will certainly block async scrolling for the GTK+ port, because of how
> > the scrolling is handled. It might also collide with other improvements in
> > composition.
> 
> Can't those be used only when in AC mode?
> 

Async scrolling requires constant AC mode. Other features will be used only when in AC mode, some might require that mode to be constant as well. What I don't want to waste time on is addressing the dynamic AC entry-and-exit functionality.

> > > I don't think cairo is the problem either.
> > 
> > It certainly is. Whenever anything is drawn, with Cairo, a backing store has
> > to be used. This means rasterizing into CPU memory that then gets copied
> > over to the GPU. So you need to first waste the CPU memory to get all the
> > backing stores updated, before you waste the GPU memory to hold all the
> > backing store content there.
> > 
> > Only improvement possible is leveraging mapping of GPU memory into
> > user-space and rasterizing with Cairo into that area. The largest problem
> > then is management of these memory areas, but I can assure you that handling
> > regularly-occurring AC entries and exits will not help one bit.
> 
> With exactly the same cairo code epiphany was unusable for most of the users
> when we switched to always use AC, and became usable again when we added the
> on demand mode. This is a fact. I would love to switch to always AC, and
> remove all the complexity of switching between modes, but we simply can't,
> at least not right now.
> 

What I'm saying is that with Cairo, when in AC mode, you will have the memory overhead for the duration between the start of painting into the backing store until all that memory is copied over to the GPU. In that context, Cairo is the problem.

Memory consumption in this case was 'improved' by removing the UpdateAtlas cache, and relying on bmalloc to efficiently allocate all the CPU memory into which the painting is done. But there's still spikes in memory consumption as long as painting is done, as described before.

> > > I think we would need to move the threaded compositor to the UI
> > > process to be able to get rid of the non accelerated rendering mode.
> > 
> > This in no way improves the backing store memory consumption problem, as
> > described above. If your argument is that OpenGL-and-GLX combo is still too
> > heavy to initialize in every WebProcess, we should be looking into adopting
> > EGL and OpenGL ES universally.
> 
> The problem was not specific to GLX, it happened exactly the same in wayland
> using EGL. The problem is quite simple, every gl context requires quite a
> bit of memory and creating the context also takes some time. When you only
> have one web view that's not a problem, the browser might be a bit slower
> once at startup and the gl context only adds some more memory. But when you
> open epiphany (or any other WebKitGTK+ based browser) with AC always
> enabled, the memory required for all the gl contexts is too much for most of
> the users. And every time you open a tab you notice the slowdown. Moving the
> compositing to the UI (or to a dedicated process as Carlos suggested) would
> use one gl context no matter how many tabs you have, fixing the problem.
> 

Do you recall how much memory that was? Cause the biggest memory issue I recall was fixed 1.5 years ago in bug #164049. Yes, GL will always have some overhead, but when taken as a percentage of the whole WebProcess consumption I don't think you'd be able to mark that overhead as critical.

When moving composition to a single process, you don't take into account that GL contexts are still needed for WebGL and GStreamer-GL. And nothing is improved regarding painting, with Cairo all the memory still has to be allocated just as before.

If the GL context creation overhead (in terms of memory and time) is a problem, how is this not an even bigger problem for you when AC is entered on demand, which can happen a bunch of times on a single page?

> > But even then, with lots of tabs open, the large majority of memory is not
> > spent on the graphics pipeline, but other things like Web content and
> > caches. You should be looking into WebProcess management instead.
> 
> If we fix all those problems with cairo and WebKitGTK+ browsers are usable
> with AC always enabled I'm open to try again, but that's not the case right
> now, with our current code the amount of memory gl adds on top makes it
> impossible.
> 

How much is that amount of memory? What percentage is it compared to the memory consumption of that whole WebProcess? Let's specify Web pages to test, and produce massif profiles and memory mapping dumps for comparison.

Anyway, my point is, why does Epiphany have to immediately spawn a WebProcess for each tab when it's launched, when I haven't even activated that tab? And why can't a WebProcess for a given tab be shut down after the tab wasn't activated for a while? That's what I meant with 'WebProcess management'.

[Michael Catanzaro]

Comment on attachment 342736 [details]
Patch

I don't see any obvious problems with this code, and I guess Zan would have pointed one out if he did. We should certainly not delay fixing a major crash like this while arguing about the future.

[Michael Catanzaro]

I would be OK with always-on AC mode if (a) it actually works for our users and (b) it doesn't involve a huge memory usage increase. Surely Carlos would be fine with it under those conditions, too, right Carlos? So Zan, if you're aware of the problems we faced last time we tried this, and think you can solve them, then I'd say go ahead. But it really needs to deliver on both points (a) and (b). I am skeptical, because the last time we tried this, from 2.13.4 until we reverted it in 2.14.4, it was a disaster. AC mode failed on both counts (a) and (b), and it failed *badly*.

Regarding (a), bug #170347 would need to be fixed first, as would bug #180739. The fact is that AC mode simply does not work for some users, and that we have historically fared poorly at responding to bug reports related to AC mode. We need to be prepared to respond *and resolve* an influx of reports that AC mode does not work on hardware that we do not own. I'm not sure how we can credibly continue this discussion without acknowledgment of this issue, as I expect it to create a substantial amount of new work for you and Miguel.

Regarding (b), you would need to look at the difference in memory usage -- with one tab open, with 20 tabs open, and with 200 tabs open -- and then we can make a value judgment as to whether any increased memory requirement is worth the maintenance benefit of removing the mode-swapping support. Last time we tried this, we had application developers who used only one or two web views in their applications complaining about dramatically increased memory use. We need to scale way beyond that.

(In reply to Zan Dobersek from comment #41)
> Anyway, my point is, why does Epiphany have to immediately spawn a
> WebProcess for each tab when it's launched, when I haven't even activated
> that tab? And why can't a WebProcess for a given tab be shut down after the
> tab wasn't activated for a while? That's what I meant with 'WebProcess
> management'.

I was going to suggest this as well. It would be highly desirable to have automatic tab discarding, similar to Chromium. And for tabs to not load until they are visited. That would be a WK2-level feature. Apple tried implementing this a year or two ago, but gave up and removed the code due to tricky problems I don't remember. So this would be a huge project to get working well enough to be used in Epiphany and Safari.

In Epiphany, we work around lack of tab discarding by loading blank pages into all of the web views on startup, but it's not good enough as the memory usage is still significant when you have too many tabs open, using a bunch of memory to show nothing.

An optimization would be to share the same web process among different tabs with the same security origin. This process model is probably needed for WebKit to remain competitive long-term. It might also be possible to create and attach the web views on demand as well, but that probably won't be useful with a per-origin process model, and it would still be just a hack. Proper solutions to these problems would be WebKit-level work.

[Carlos Garcia Campos]

(In reply to Zan Dobersek from comment #41)
> (In reply to Carlos Garcia Campos from comment #40)
> > (In reply to Zan Dobersek from comment #34)
> > > (In reply to Carlos Garcia Campos from comment #31)
> > > > (In reply to Zan Dobersek from comment #26)
> > > > > Comment on attachment 342736 [details]
> > > > > Patch
> > > > > 
> > > > > View in context:
> > > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review
> > > > > 
> > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
> > > > > > +    // If the coordinators are different it means that we are attaching a layer that was created by a different
> > > > > > +    // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree
> > > > > > +    // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the
> > > > > > +    // layer and its children.
> > > > > 
> > > > > The dynamic AC entry and exit continues to produce bugs and require fixes
> > > > > that only complicate the CoordinatedGraphics stack and any future
> > > > > improvements. I propose WebKitGTK+ adds an API that for the specific
> > > > > UIProcess instance either enables or disables AC, but otherwise abandons
> > > > > dynamic AC entry and exit.
> > > > 
> > > > It's actually revealing existing bugs in most of the cases I would say. But
> > > > still, we are not going to change it.
> > > 
> > > This will certainly block async scrolling for the GTK+ port, because of how
> > > the scrolling is handled. It might also collide with other improvements in
> > > composition.
> > 
> > Can't those be used only when in AC mode?
> > 
> 
> Async scrolling requires constant AC mode. Other features will be used only
> when in AC mode, some might require that mode to be constant as well. What I
> don't want to waste time on is addressing the dynamic AC entry-and-exit
> functionality.

We won't be able to use async scrolling in GTK for now then. We have no choice right now.

> > > > I don't think cairo is the problem either.
> > > 
> > > It certainly is. Whenever anything is drawn, with Cairo, a backing store has
> > > to be used. This means rasterizing into CPU memory that then gets copied
> > > over to the GPU. So you need to first waste the CPU memory to get all the
> > > backing stores updated, before you waste the GPU memory to hold all the
> > > backing store content there.
> > > 
> > > Only improvement possible is leveraging mapping of GPU memory into
> > > user-space and rasterizing with Cairo into that area. The largest problem
> > > then is management of these memory areas, but I can assure you that handling
> > > regularly-occurring AC entries and exits will not help one bit.
> > 
> > With exactly the same cairo code epiphany was unusable for most of the users
> > when we switched to always use AC, and became usable again when we added the
> > on demand mode. This is a fact. I would love to switch to always AC, and
> > remove all the complexity of switching between modes, but we simply can't,
> > at least not right now.
> > 
> 
> What I'm saying is that with Cairo, when in AC mode, you will have the
> memory overhead for the duration between the start of painting into the
> backing store until all that memory is copied over to the GPU. In that
> context, Cairo is the problem.

Yes, but the checks we did at the time were with about:blank pages. So, I believe you that cairo adds more overhead on top.

> Memory consumption in this case was 'improved' by removing the UpdateAtlas
> cache, and relying on bmalloc to efficiently allocate all the CPU memory
> into which the painting is done. But there's still spikes in memory
> consumption as long as painting is done, as described before.
> 
> > > > I think we would need to move the threaded compositor to the UI
> > > > process to be able to get rid of the non accelerated rendering mode.
> > > 
> > > This in no way improves the backing store memory consumption problem, as
> > > described above. If your argument is that OpenGL-and-GLX combo is still too
> > > heavy to initialize in every WebProcess, we should be looking into adopting
> > > EGL and OpenGL ES universally.
> > 
> > The problem was not specific to GLX, it happened exactly the same in wayland
> > using EGL. The problem is quite simple, every gl context requires quite a
> > bit of memory and creating the context also takes some time. When you only
> > have one web view that's not a problem, the browser might be a bit slower
> > once at startup and the gl context only adds some more memory. But when you
> > open epiphany (or any other WebKitGTK+ based browser) with AC always
> > enabled, the memory required for all the gl contexts is too much for most of
> > the users. And every time you open a tab you notice the slowdown. Moving the
> > compositing to the UI (or to a dedicated process as Carlos suggested) would
> > use one gl context no matter how many tabs you have, fixing the problem.
> > 
> 
> Do you recall how much memory that was? Cause the biggest memory issue I
> recall was fixed 1.5 years ago in bug #164049. Yes, GL will always have some
> overhead, but when taken as a percentage of the whole WebProcess consumption
> I don't think you'd be able to mark that overhead as critical.

I don't remember, it was small for a single tab, but too much for many tabs. With current trunk loading about:blank in MiniBrowser I get:

 - Wayland no AC: UI: 17,3MB Web: 16,5MB
 - Wayland AC: UI: 26,5MB Web: 22,3MB
 - X11 no AC: UI: 12,6MB Web: 13,9MB
 - X11 AC: UI: 14,5MB Web: 21,1MB

> When moving composition to a single process, you don't take into account
> that GL contexts are still needed for WebGL and GStreamer-GL. And nothing is
> improved regarding painting, with Cairo all the memory still has to be
> allocated just as before.

It's fine if only tabs currently using WebGL and GStreamer use additional gl contexts, the same way it's fine right now that some tabs have AC mode enabled.

> If the GL context creation overhead (in terms of memory and time) is a
> problem, how is this not an even bigger problem for you when AC is entered
> on demand, which can happen a bunch of times on a single page?

When a page enters and leaves AC, it's a single page doing so, I insist that the problem is having Ac enabled in all the pages. Note that when a page enters AC due to a condition change, an animation ro whatever, the page is already rendered so you are seeing the contents, not a white (or even black) page. Starting epiphany with a single or even a few tabs with AC enabled, was a bit slower but acceptable. But with some more tabs the thing was very noticeable. Not to mention resizing the window.

> > > But even then, with lots of tabs open, the large majority of memory is not
> > > spent on the graphics pipeline, but other things like Web content and
> > > caches. You should be looking into WebProcess management instead.
> > 
> > If we fix all those problems with cairo and WebKitGTK+ browsers are usable
> > with AC always enabled I'm open to try again, but that's not the case right
> > now, with our current code the amount of memory gl adds on top makes it
> > impossible.
> > 
> 
> How much is that amount of memory? What percentage is it compared to the
> memory consumption of that whole WebProcess? Let's specify Web pages to
> test, and produce massif profiles and memory mapping dumps for comparison.

It's not that much percentage for a single web process. If the overhead of cairo or any other thing is solved and makes this one insignificant, then I'm open to try again, but we need to fix those first.

> Anyway, my point is, why does Epiphany have to immediately spawn a
> WebProcess for each tab when it's launched, when I haven't even activated
> that tab? And why can't a WebProcess for a given tab be shut down after the
> tab wasn't activated for a while? That's what I meant with 'WebProcess
> management'.

We could make improvements in process management, but they are not easy at all. Any improvement there to should be done in WebKit, not in the browser side. There are things that browsers can do, though, for example epiphany delays the loads of tabs until they are activated, by using placeholder tabs consisting of about:blank with a title. But a bunch of about:blank pages was still a problem in terms of memory and startup times.

As Michael suggested we also have the problem of drivers. To enable AC unconditionally we need a way to get detailed information from users having problems. I thought about adding about:gpu or whatever, to show information about the gpu, the driver, the gl context, the opengl version profile, the extensions available, etc. With the idea of using HardwareAccelerationManager.cpp to blacklist known buggy drivers.

Any change in this needs to be done at the very beginning of a release cycle.

[Miguel Gomez]

Well, as this approach seem to be problematic for Zan's plans, I'll try to fix this by destroying the CoordinatedGraphicsLayers.

[Zan Dobersek]

(In reply to Miguel Gomez from comment #45)
> Well, as this approach seem to be problematic for Zan's plans, I'll try to
> fix this by destroying the CoordinatedGraphicsLayers.

Don't know what approach this means taking, but with the exception of the root layer we don't own these objects.

[Zan Dobersek]

(In reply to Michael Catanzaro from comment #43)
> I would be OK with always-on AC mode if (a) it actually works for our users
> and (b) it doesn't involve a huge memory usage increase. Surely Carlos would
> be fine with it under those conditions, too, right Carlos? So Zan, if you're
> aware of the problems we faced last time we tried this, and think you can
> solve them, then I'd say go ahead. But it really needs to deliver on both
> points (a) and (b). I am skeptical, because the last time we tried this,
> from 2.13.4 until we reverted it in 2.14.4, it was a disaster. AC mode
> failed on both counts (a) and (b), and it failed *badly*.
> 
> Regarding (a), bug #170347 would need to be fixed first, as would bug
> #180739. The fact is that AC mode simply does not work for some users, and
> that we have historically fared poorly at responding to bug reports related
> to AC mode. We need to be prepared to respond *and resolve* an influx of
> reports that AC mode does not work on hardware that we do not own. I'm not
> sure how we can credibly continue this discussion without acknowledgment of
> this issue, as I expect it to create a substantial amount of new work for
> you and Miguel.
> 

On our side, we can only work against an OpenGL+GLX or OpenGLES+EGL library. Driver bugs are not ours to fix.

> Regarding (b), you would need to look at the difference in memory usage --
> with one tab open, with 20 tabs open, and with 200 tabs open -- and then we
> can make a value judgment as to whether any increased memory requirement is
> worth the maintenance benefit of removing the mode-swapping support. Last
> time we tried this, we had application developers who used only one or two
> web views in their applications complaining about dramatically increased
> memory use. We need to scale way beyond that.
> 

How well do you think you scale even with AC disabled if you volunteer to spawn a WebProcess for each tab when upon launch?

> (In reply to Zan Dobersek from comment #41)
> > Anyway, my point is, why does Epiphany have to immediately spawn a
> > WebProcess for each tab when it's launched, when I haven't even activated
> > that tab? And why can't a WebProcess for a given tab be shut down after the
> > tab wasn't activated for a while? That's what I meant with 'WebProcess
> > management'.
> 
> I was going to suggest this as well. It would be highly desirable to have
> automatic tab discarding, similar to Chromium. And for tabs to not load
> until they are visited. That would be a WK2-level feature. Apple tried
> implementing this a year or two ago, but gave up and removed the code due to
> tricky problems I don't remember. So this would be a huge project to get
> working well enough to be used in Epiphany and Safari.
> 

This is a current feature of the Safari browser. I don't know at what level it's implemented.

> In Epiphany, we work around lack of tab discarding by loading blank pages
> into all of the web views on startup, but it's not good enough as the memory
> usage is still significant when you have too many tabs open, using a bunch
> of memory to show nothing.
> 
> An optimization would be to share the same web process among different tabs
> with the same security origin. This process model is probably needed for
> WebKit to remain competitive long-term. It might also be possible to create
> and attach the web views on demand as well, but that probably won't be
> useful with a per-origin process model, and it would still be just a hack.
> Proper solutions to these problems would be WebKit-level work.

Can you explain why this can't be done in Epiphany?

[Zan Dobersek]

(In reply to Carlos Garcia Campos from comment #44)
> (In reply to Zan Dobersek from comment #41)
> > (In reply to Carlos Garcia Campos from comment #40)
> > > (In reply to Zan Dobersek from comment #34)
> > > > (In reply to Carlos Garcia Campos from comment #31)
> > > > > (In reply to Zan Dobersek from comment #26)
> > > > > > Comment on attachment 342736 [details]
> > > > > > Patch
> > > > > > 
> > > > > > View in context:
> > > > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review
> > > > > > 
> > > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
> > > > > > > +    // If the coordinators are different it means that we are attaching a layer that was created by a different
> > > > > > > +    // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree
> > > > > > > +    // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the
> > > > > > > +    // layer and its children.
> > > > > > 
> > > > > > The dynamic AC entry and exit continues to produce bugs and require fixes
> > > > > > that only complicate the CoordinatedGraphics stack and any future
> > > > > > improvements. I propose WebKitGTK+ adds an API that for the specific
> > > > > > UIProcess instance either enables or disables AC, but otherwise abandons
> > > > > > dynamic AC entry and exit.
> > > > > 
> > > > > It's actually revealing existing bugs in most of the cases I would say. But
> > > > > still, we are not going to change it.
> > > > 
> > > > This will certainly block async scrolling for the GTK+ port, because of how
> > > > the scrolling is handled. It might also collide with other improvements in
> > > > composition.
> > > 
> > > Can't those be used only when in AC mode?
> > > 
> > 
> > Async scrolling requires constant AC mode. Other features will be used only
> > when in AC mode, some might require that mode to be constant as well. What I
> > don't want to waste time on is addressing the dynamic AC entry-and-exit
> > functionality.
> 
> We won't be able to use async scrolling in GTK for now then. We have no
> choice right now.
> 

OK.

> > > > > I don't think cairo is the problem either.
> > > > 
> > > > It certainly is. Whenever anything is drawn, with Cairo, a backing store has
> > > > to be used. This means rasterizing into CPU memory that then gets copied
> > > > over to the GPU. So you need to first waste the CPU memory to get all the
> > > > backing stores updated, before you waste the GPU memory to hold all the
> > > > backing store content there.
> > > > 
> > > > Only improvement possible is leveraging mapping of GPU memory into
> > > > user-space and rasterizing with Cairo into that area. The largest problem
> > > > then is management of these memory areas, but I can assure you that handling
> > > > regularly-occurring AC entries and exits will not help one bit.
> > > 
> > > With exactly the same cairo code epiphany was unusable for most of the users
> > > when we switched to always use AC, and became usable again when we added the
> > > on demand mode. This is a fact. I would love to switch to always AC, and
> > > remove all the complexity of switching between modes, but we simply can't,
> > > at least not right now.
> > > 
> > 
> > What I'm saying is that with Cairo, when in AC mode, you will have the
> > memory overhead for the duration between the start of painting into the
> > backing store until all that memory is copied over to the GPU. In that
> > context, Cairo is the problem.
> 
> Yes, but the checks we did at the time were with about:blank pages. So, I
> believe you that cairo adds more overhead on top.
> 

about:blank still requires Cairo to render all the whiteness (yes, really). So 8MB had to be allocated for that alone when in 1080p resolution. This is not the case anymore, but I think that's already reflected in your measurements below.

> > Memory consumption in this case was 'improved' by removing the UpdateAtlas
> > cache, and relying on bmalloc to efficiently allocate all the CPU memory
> > into which the painting is done. But there's still spikes in memory
> > consumption as long as painting is done, as described before.
> > 
> > > > > I think we would need to move the threaded compositor to the UI
> > > > > process to be able to get rid of the non accelerated rendering mode.
> > > > 
> > > > This in no way improves the backing store memory consumption problem, as
> > > > described above. If your argument is that OpenGL-and-GLX combo is still too
> > > > heavy to initialize in every WebProcess, we should be looking into adopting
> > > > EGL and OpenGL ES universally.
> > > 
> > > The problem was not specific to GLX, it happened exactly the same in wayland
> > > using EGL. The problem is quite simple, every gl context requires quite a
> > > bit of memory and creating the context also takes some time. When you only
> > > have one web view that's not a problem, the browser might be a bit slower
> > > once at startup and the gl context only adds some more memory. But when you
> > > open epiphany (or any other WebKitGTK+ based browser) with AC always
> > > enabled, the memory required for all the gl contexts is too much for most of
> > > the users. And every time you open a tab you notice the slowdown. Moving the
> > > compositing to the UI (or to a dedicated process as Carlos suggested) would
> > > use one gl context no matter how many tabs you have, fixing the problem.
> > > 
> > 
> > Do you recall how much memory that was? Cause the biggest memory issue I
> > recall was fixed 1.5 years ago in bug #164049. Yes, GL will always have some
> > overhead, but when taken as a percentage of the whole WebProcess consumption
> > I don't think you'd be able to mark that overhead as critical.
> 
> I don't remember, it was small for a single tab, but too much for many tabs.
> With current trunk loading about:blank in MiniBrowser I get:
> 
>  - Wayland no AC: UI: 17,3MB Web: 16,5MB
>  - Wayland AC: UI: 26,5MB Web: 22,3MB
>  - X11 no AC: UI: 12,6MB Web: 13,9MB
>  - X11 AC: UI: 14,5MB Web: 21,1MB
> 

How does this difference scale on a real-life page? Like I said, let's specify the sites and do the measurements.

> > When moving composition to a single process, you don't take into account
> > that GL contexts are still needed for WebGL and GStreamer-GL. And nothing is
> > improved regarding painting, with Cairo all the memory still has to be
> > allocated just as before.
> 
> It's fine if only tabs currently using WebGL and GStreamer use additional gl
> contexts, the same way it's fine right now that some tabs have AC mode
> enabled.
> 
> > If the GL context creation overhead (in terms of memory and time) is a
> > problem, how is this not an even bigger problem for you when AC is entered
> > on demand, which can happen a bunch of times on a single page?
> 
> When a page enters and leaves AC, it's a single page doing so, I insist that
> the problem is having Ac enabled in all the pages.

IMO it's only a problem if you do no management of the idle pages. Or if you go out and spawn about:blank pages for every tab.

> Note that when a page
> enters AC due to a condition change, an animation ro whatever, the page is
> already rendered so you are seeing the contents, not a white (or even black)
> page. Starting epiphany with a single or even a few tabs with AC enabled,
> was a bit slower but acceptable. But with some more tabs the thing was very
> noticeable. Not to mention resizing the window.
> 

Why is resizing the window an issue here? Is every web view being resized when you're doing that?

I don't think you're rendering every loaded tab all the time, even if it's not focused?

> > > > But even then, with lots of tabs open, the large majority of memory is not
> > > > spent on the graphics pipeline, but other things like Web content and
> > > > caches. You should be looking into WebProcess management instead.
> > > 
> > > If we fix all those problems with cairo and WebKitGTK+ browsers are usable
> > > with AC always enabled I'm open to try again, but that's not the case right
> > > now, with our current code the amount of memory gl adds on top makes it
> > > impossible.
> > > 
> > 
> > How much is that amount of memory? What percentage is it compared to the
> > memory consumption of that whole WebProcess? Let's specify Web pages to
> > test, and produce massif profiles and memory mapping dumps for comparison.
> 
> It's not that much percentage for a single web process. If the overhead of
> cairo or any other thing is solved and makes this one insignificant, then
> I'm open to try again, but we need to fix those first.
> 

This just feels like from the memory consumption POV, we the graphics people are being asked to produce a miracle to reduce the memory burden that originates from spawning about:blank tabs.

> > Anyway, my point is, why does Epiphany have to immediately spawn a
> > WebProcess for each tab when it's launched, when I haven't even activated
> > that tab? And why can't a WebProcess for a given tab be shut down after the
> > tab wasn't activated for a while? That's what I meant with 'WebProcess
> > management'.
> 
> We could make improvements in process management, but they are not easy at
> all. Any improvement there to should be done in WebKit, not in the browser
> side. There are things that browsers can do, though, for example epiphany
> delays the loads of tabs until they are activated, by using placeholder tabs
> consisting of about:blank with a title. But a bunch of about:blank pages was
> still a problem in terms of memory and startup times.
> 

Again, I'd really like to hear why this can't be done at the browser level, or rather what still needs to be done at the WebKit level.

> As Michael suggested we also have the problem of drivers. To enable AC
> unconditionally we need a way to get detailed information from users having
> problems. I thought about adding about:gpu or whatever, to show information
> about the gpu, the driver, the gl context, the opengl version profile, the
> extensions available, etc. With the idea of using
> HardwareAccelerationManager.cpp to blacklist known buggy drivers.
> 
> Any change in this needs to be done at the very beginning of a release cycle.

OK, understandable.

[Michael Catanzaro]

(In reply to Zan Dobersek from comment #47)
> On our side, we can only work against an OpenGL+GLX or OpenGLES+EGL library.
> Driver bugs are not ours to fix.

Other major browsers have GPU blacklists when there are unfixable driver bugs. If we can't take responsibility for whether WebKit ultimately works or not, then we can't do GPU rendering. Sorry, but driver bugs are common.

> How well do you think you scale even with AC disabled if you volunteer to
> spawn a WebProcess for each tab when upon launch?

I just tested 180 blank tabs and it works fine, though it requires a lot of memory.

> > (In reply to Zan Dobersek from comment #41)
> This is a current feature of the Safari browser. I don't know at what level
> it's implemented.

You're sure? I remember when this code was added to and removed from WebKit. When I search for "Safari tab discarding," all the results relevant to tab discarding are for Chrome.

Anyway, we don't implement complex low-level features at the browser level, we do it in WebKit. Especially since it's going to require information that's only available to WebKit to handle properly, e.g. whether a page has unload handlers, or whether a page is in page cache. 

> > In Epiphany, we work around lack of tab discarding by loading blank pages
> > into all of the web views on startup, but it's not good enough as the memory
> > usage is still significant when you have too many tabs open, using a bunch
> > of memory to show nothing.
> > 
> > An optimization would be to share the same web process among different tabs
> > with the same security origin. This process model is probably needed for
> > WebKit to remain competitive long-term. It might also be possible to create
> > and attach the web views on demand as well, but that probably won't be
> > useful with a per-origin process model, and it would still be just a hack.
> > Proper solutions to these problems would be WebKit-level work.
> 
> Can you explain why this can't be done in Epiphany?

Because process launching is controlled by WebKit. Epiphany doesn't have any way to control which processes WebKit chooses to launch. We would need to add a new WebKitProcessModel. It would require changes throughout WebKit, because WebKit is not currently designed to support a per-origin process model. E.g. iframes need to be launched in the right process. We need a web compat plan for how to handle windows no longer having access to parent and child windows, since many websites will break (Apple is currently working on this with Google). That can only be handled in WebCore. And it all depends on Apple's process swap on navigation work, which is still experimental.

(In reply to Zan Dobersek from comment #48)
> This just feels like from the memory consumption POV, we the graphics people
> are being asked to produce a miracle to reduce the memory burden that
> originates from spawning about:blank tabs.

Why do you think this is not a useful test? about:blank is just useful to show how much memory is required for a WebKitWebView to display nothing. It's a fact that AC mode requires more memory. You can compare with any website you prefer to use instead, so long as it doesn't ordinarily trigger AC mode.

[Michael Catanzaro]

www.gnome.org in Wayland:

AC mode: UI 39.4 MiB, web 156.3 MiB
Non AC: UI 31.1 MiB, 129.8 MiB

Counting only the difference in web process memory usage, the difference would reach 1 GB more memory consumed at around 40 tabs.

[Carlos Garcia Campos]

(In reply to Zan Dobersek from comment #48)
> (In reply to Carlos Garcia Campos from comment #44)
> > (In reply to Zan Dobersek from comment #41)
> > > (In reply to Carlos Garcia Campos from comment #40)
> > > > (In reply to Zan Dobersek from comment #34)
> > > > > (In reply to Carlos Garcia Campos from comment #31)
> > > > > > (In reply to Zan Dobersek from comment #26)
> > > > > > > Comment on attachment 342736 [details]
> > > > > > > Patch
> > > > > > > 
> > > > > > > View in context:
> > > > > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review
> > > > > > > 
> > > > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
> > > > > > > > +    // If the coordinators are different it means that we are attaching a layer that was created by a different
> > > > > > > > +    // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree
> > > > > > > > +    // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the
> > > > > > > > +    // layer and its children.
> > > > > > > 
> > > > > > > The dynamic AC entry and exit continues to produce bugs and require fixes
> > > > > > > that only complicate the CoordinatedGraphics stack and any future
> > > > > > > improvements. I propose WebKitGTK+ adds an API that for the specific
> > > > > > > UIProcess instance either enables or disables AC, but otherwise abandons
> > > > > > > dynamic AC entry and exit.
> > > > > > 
> > > > > > It's actually revealing existing bugs in most of the cases I would say. But
> > > > > > still, we are not going to change it.
> > > > > 
> > > > > This will certainly block async scrolling for the GTK+ port, because of how
> > > > > the scrolling is handled. It might also collide with other improvements in
> > > > > composition.
> > > > 
> > > > Can't those be used only when in AC mode?
> > > > 
> > > 
> > > Async scrolling requires constant AC mode. Other features will be used only
> > > when in AC mode, some might require that mode to be constant as well. What I
> > > don't want to waste time on is addressing the dynamic AC entry-and-exit
> > > functionality.
> > 
> > We won't be able to use async scrolling in GTK for now then. We have no
> > choice right now.
> > 
> 
> OK.
> 
> > > > > > I don't think cairo is the problem either.
> > > > > 
> > > > > It certainly is. Whenever anything is drawn, with Cairo, a backing store has
> > > > > to be used. This means rasterizing into CPU memory that then gets copied
> > > > > over to the GPU. So you need to first waste the CPU memory to get all the
> > > > > backing stores updated, before you waste the GPU memory to hold all the
> > > > > backing store content there.
> > > > > 
> > > > > Only improvement possible is leveraging mapping of GPU memory into
> > > > > user-space and rasterizing with Cairo into that area. The largest problem
> > > > > then is management of these memory areas, but I can assure you that handling
> > > > > regularly-occurring AC entries and exits will not help one bit.
> > > > 
> > > > With exactly the same cairo code epiphany was unusable for most of the users
> > > > when we switched to always use AC, and became usable again when we added the
> > > > on demand mode. This is a fact. I would love to switch to always AC, and
> > > > remove all the complexity of switching between modes, but we simply can't,
> > > > at least not right now.
> > > > 
> > > 
> > > What I'm saying is that with Cairo, when in AC mode, you will have the
> > > memory overhead for the duration between the start of painting into the
> > > backing store until all that memory is copied over to the GPU. In that
> > > context, Cairo is the problem.
> > 
> > Yes, but the checks we did at the time were with about:blank pages. So, I
> > believe you that cairo adds more overhead on top.
> > 
> 
> about:blank still requires Cairo to render all the whiteness (yes, really).
> So 8MB had to be allocated for that alone when in 1080p resolution. This is
> not the case anymore, but I think that's already reflected in your
> measurements below.

I remember I compared the memory consumption with chrome at the time and the numbers were very similar, with the difference that chrome only had one context in the gpu process instead of one per tab.

> > > Memory consumption in this case was 'improved' by removing the UpdateAtlas
> > > cache, and relying on bmalloc to efficiently allocate all the CPU memory
> > > into which the painting is done. But there's still spikes in memory
> > > consumption as long as painting is done, as described before.
> > > 
> > > > > > I think we would need to move the threaded compositor to the UI
> > > > > > process to be able to get rid of the non accelerated rendering mode.
> > > > > 
> > > > > This in no way improves the backing store memory consumption problem, as
> > > > > described above. If your argument is that OpenGL-and-GLX combo is still too
> > > > > heavy to initialize in every WebProcess, we should be looking into adopting
> > > > > EGL and OpenGL ES universally.
> > > > 
> > > > The problem was not specific to GLX, it happened exactly the same in wayland
> > > > using EGL. The problem is quite simple, every gl context requires quite a
> > > > bit of memory and creating the context also takes some time. When you only
> > > > have one web view that's not a problem, the browser might be a bit slower
> > > > once at startup and the gl context only adds some more memory. But when you
> > > > open epiphany (or any other WebKitGTK+ based browser) with AC always
> > > > enabled, the memory required for all the gl contexts is too much for most of
> > > > the users. And every time you open a tab you notice the slowdown. Moving the
> > > > compositing to the UI (or to a dedicated process as Carlos suggested) would
> > > > use one gl context no matter how many tabs you have, fixing the problem.
> > > > 
> > > 
> > > Do you recall how much memory that was? Cause the biggest memory issue I
> > > recall was fixed 1.5 years ago in bug #164049. Yes, GL will always have some
> > > overhead, but when taken as a percentage of the whole WebProcess consumption
> > > I don't think you'd be able to mark that overhead as critical.
> > 
> > I don't remember, it was small for a single tab, but too much for many tabs.
> > With current trunk loading about:blank in MiniBrowser I get:
> > 
> >  - Wayland no AC: UI: 17,3MB Web: 16,5MB
> >  - Wayland AC: UI: 26,5MB Web: 22,3MB
> >  - X11 no AC: UI: 12,6MB Web: 13,9MB
> >  - X11 AC: UI: 14,5MB Web: 21,1MB
> > 
> 
> How does this difference scale on a real-life page? Like I said, let's
> specify the sites and do the measurements.

Using about:blank is just a way to set a minimum, any other website will use at least that.

> > > When moving composition to a single process, you don't take into account
> > > that GL contexts are still needed for WebGL and GStreamer-GL. And nothing is
> > > improved regarding painting, with Cairo all the memory still has to be
> > > allocated just as before.
> > 
> > It's fine if only tabs currently using WebGL and GStreamer use additional gl
> > contexts, the same way it's fine right now that some tabs have AC mode
> > enabled.
> > 
> > > If the GL context creation overhead (in terms of memory and time) is a
> > > problem, how is this not an even bigger problem for you when AC is entered
> > > on demand, which can happen a bunch of times on a single page?
> > 
> > When a page enters and leaves AC, it's a single page doing so, I insist that
> > the problem is having Ac enabled in all the pages.
> 
> IMO it's only a problem if you do no management of the idle pages. Or if you
> go out and spawn about:blank pages for every tab.

That requires changes in WebKit much more complex than having AC on demand.

> > Note that when a page
> > enters AC due to a condition change, an animation ro whatever, the page is
> > already rendered so you are seeing the contents, not a white (or even black)
> > page. Starting epiphany with a single or even a few tabs with AC enabled,
> > was a bit slower but acceptable. But with some more tabs the thing was very
> > noticeable. Not to mention resizing the window.
> > 
> 
> Why is resizing the window an issue here? Is every web view being resized
> when you're doing that?

Yes.

> I don't think you're rendering every loaded tab all the time, even if it's
> not focused?

No, painting is suspended, but other things are done, because otherwise when you switch to another tab you see flickering or even worse effects.

> > > > > But even then, with lots of tabs open, the large majority of memory is not
> > > > > spent on the graphics pipeline, but other things like Web content and
> > > > > caches. You should be looking into WebProcess management instead.
> > > > 
> > > > If we fix all those problems with cairo and WebKitGTK+ browsers are usable
> > > > with AC always enabled I'm open to try again, but that's not the case right
> > > > now, with our current code the amount of memory gl adds on top makes it
> > > > impossible.
> > > > 
> > > 
> > > How much is that amount of memory? What percentage is it compared to the
> > > memory consumption of that whole WebProcess? Let's specify Web pages to
> > > test, and produce massif profiles and memory mapping dumps for comparison.
> > 
> > It's not that much percentage for a single web process. If the overhead of
> > cairo or any other thing is solved and makes this one insignificant, then
> > I'm open to try again, but we need to fix those first.
> > 
> 
> This just feels like from the memory consumption POV, we the graphics people
> are being asked to produce a miracle to reduce the memory burden that
> originates from spawning about:blank tabs.

No, that's why we want to have AC on demand, because we know that gl requires more memory and we can't do anything about it. I'm sure we can do improvements on the graphics side, but to be able to switch to always AC we will require more changes in other parts (process management, idle tabs, etc.)

> > > Anyway, my point is, why does Epiphany have to immediately spawn a
> > > WebProcess for each tab when it's launched, when I haven't even activated
> > > that tab? And why can't a WebProcess for a given tab be shut down after the
> > > tab wasn't activated for a while? That's what I meant with 'WebProcess
> > > management'.
> > 
> > We could make improvements in process management, but they are not easy at
> > all. Any improvement there to should be done in WebKit, not in the browser
> > side. There are things that browsers can do, though, for example epiphany
> > delays the loads of tabs until they are activated, by using placeholder tabs
> > consisting of about:blank with a title. But a bunch of about:blank pages was
> > still a problem in terms of memory and startup times.
> > 
> 
> Again, I'd really like to hear why this can't be done at the browser level,
> or rather what still needs to be done at the WebKit level.

WebKit is the one spawning the processes, at the browser level we can only not create a web view to avoid the process from being launched. But the point is that we don't want to fix only epiphany, all WebKitGTK+ based applications should benefit from whatever we improve here.

> > As Michael suggested we also have the problem of drivers. To enable AC
> > unconditionally we need a way to get detailed information from users having
> > problems. I thought about adding about:gpu or whatever, to show information
> > about the gpu, the driver, the gl context, the opengl version profile, the
> > extensions available, etc. With the idea of using
> > HardwareAccelerationManager.cpp to blacklist known buggy drivers.
> > 
> > Any change in this needs to be done at the very beginning of a release cycle.
> 
> OK, understandable.

It's clear that we can't switch to AC always *right now*, but we might by adopting any or several of the proposals made here. Some of them could be easy to try and some others are more long term goals. So, I propose to list and prioritize things we can do. For example:

 - Keep AC on demand, but never exit AC once entered for the same website/origin. I liked this idea, it's not a long term solution, but could be easily implemented and would avoid enter/leaves just when a tooltip is shown, for example.

 - Improve the memory consumption on the graphics side (cairo).

 - Add one process per origin process model.

 - Implement tab suspending.

 - Move the compositing to the UI or dedicated gpu process.

 - Make it possible to blacklist gpus, and add about:gpu to make it easier to collect the required info from users.

Any other idea? Note these tasks are not mutually exclusive, and some of them are blockers like the gpu blacklisting.

[Miguel Gomez]

>  - Keep AC on demand, but never exit AC once entered for the same
> website/origin. I liked this idea, it's not a long term solution, but could
> be easily implemented and would avoid enter/leaves just when a tooltip is
> shown, for example.

If this is a valid option, it's the easiest way to fix this bug.

[Carlos Garcia Campos]

(In reply to Miguel Gomez from comment #52)
> >  - Keep AC on demand, but never exit AC once entered for the same
> > website/origin. I liked this idea, it's not a long term solution, but could
> > be easily implemented and would avoid enter/leaves just when a tooltip is
> > shown, for example.
> 
> If this is a valid option, it's the easiest way to fix this bug.

Yes, I think it's good short-term solution to this bug while we develop a long term solution to be able to switch to AC mode always enabled. Note that I said for the same website/origin, not for the same webview.

[Zan Dobersek]

(In reply to Carlos Garcia Campos from comment #51)
> (In reply to Zan Dobersek from comment #48)
> > (In reply to Carlos Garcia Campos from comment #44)
> > > (In reply to Zan Dobersek from comment #41)
> > > > (In reply to Carlos Garcia Campos from comment #40)
> > > > > (In reply to Zan Dobersek from comment #34)
> > > > > > (In reply to Carlos Garcia Campos from comment #31)
> > > > > > > (In reply to Zan Dobersek from comment #26)
> > > > > > > > Comment on attachment 342736 [details]
> > > > > > > > Patch
> > > > > > > > 
> > > > > > > > View in context:
> > > > > > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review
> > > > > > > > 
> > > > > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009
> > > > > > > > > +    // If the coordinators are different it means that we are attaching a layer that was created by a different
> > > > > > > > > +    // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree
> > > > > > > > > +    // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the
> > > > > > > > > +    // layer and its children.
> > > > > > > > 
> > > > > > > > The dynamic AC entry and exit continues to produce bugs and require fixes
> > > > > > > > that only complicate the CoordinatedGraphics stack and any future
> > > > > > > > improvements. I propose WebKitGTK+ adds an API that for the specific
> > > > > > > > UIProcess instance either enables or disables AC, but otherwise abandons
> > > > > > > > dynamic AC entry and exit.
> > > > > > > 
> > > > > > > It's actually revealing existing bugs in most of the cases I would say. But
> > > > > > > still, we are not going to change it.
> > > > > > 
> > > > > > This will certainly block async scrolling for the GTK+ port, because of how
> > > > > > the scrolling is handled. It might also collide with other improvements in
> > > > > > composition.
> > > > > 
> > > > > Can't those be used only when in AC mode?
> > > > > 
> > > > 
> > > > Async scrolling requires constant AC mode. Other features will be used only
> > > > when in AC mode, some might require that mode to be constant as well. What I
> > > > don't want to waste time on is addressing the dynamic AC entry-and-exit
> > > > functionality.
> > > 
> > > We won't be able to use async scrolling in GTK for now then. We have no
> > > choice right now.
> > > 
> > 
> > OK.
> > 
> > > > > > > I don't think cairo is the problem either.
> > > > > > 
> > > > > > It certainly is. Whenever anything is drawn, with Cairo, a backing store has
> > > > > > to be used. This means rasterizing into CPU memory that then gets copied
> > > > > > over to the GPU. So you need to first waste the CPU memory to get all the
> > > > > > backing stores updated, before you waste the GPU memory to hold all the
> > > > > > backing store content there.
> > > > > > 
> > > > > > Only improvement possible is leveraging mapping of GPU memory into
> > > > > > user-space and rasterizing with Cairo into that area. The largest problem
> > > > > > then is management of these memory areas, but I can assure you that handling
> > > > > > regularly-occurring AC entries and exits will not help one bit.
> > > > > 
> > > > > With exactly the same cairo code epiphany was unusable for most of the users
> > > > > when we switched to always use AC, and became usable again when we added the
> > > > > on demand mode. This is a fact. I would love to switch to always AC, and
> > > > > remove all the complexity of switching between modes, but we simply can't,
> > > > > at least not right now.
> > > > > 
> > > > 
> > > > What I'm saying is that with Cairo, when in AC mode, you will have the
> > > > memory overhead for the duration between the start of painting into the
> > > > backing store until all that memory is copied over to the GPU. In that
> > > > context, Cairo is the problem.
> > > 
> > > Yes, but the checks we did at the time were with about:blank pages. So, I
> > > believe you that cairo adds more overhead on top.
> > > 
> > 
> > about:blank still requires Cairo to render all the whiteness (yes, really).
> > So 8MB had to be allocated for that alone when in 1080p resolution. This is
> > not the case anymore, but I think that's already reflected in your
> > measurements below.
> 
> I remember I compared the memory consumption with chrome at the time and the
> numbers were very similar, with the difference that chrome only had one
> context in the gpu process instead of one per tab.
> 
> > > > Memory consumption in this case was 'improved' by removing the UpdateAtlas
> > > > cache, and relying on bmalloc to efficiently allocate all the CPU memory
> > > > into which the painting is done. But there's still spikes in memory
> > > > consumption as long as painting is done, as described before.
> > > > 
> > > > > > > I think we would need to move the threaded compositor to the UI
> > > > > > > process to be able to get rid of the non accelerated rendering mode.
> > > > > > 
> > > > > > This in no way improves the backing store memory consumption problem, as
> > > > > > described above. If your argument is that OpenGL-and-GLX combo is still too
> > > > > > heavy to initialize in every WebProcess, we should be looking into adopting
> > > > > > EGL and OpenGL ES universally.
> > > > > 
> > > > > The problem was not specific to GLX, it happened exactly the same in wayland
> > > > > using EGL. The problem is quite simple, every gl context requires quite a
> > > > > bit of memory and creating the context also takes some time. When you only
> > > > > have one web view that's not a problem, the browser might be a bit slower
> > > > > once at startup and the gl context only adds some more memory. But when you
> > > > > open epiphany (or any other WebKitGTK+ based browser) with AC always
> > > > > enabled, the memory required for all the gl contexts is too much for most of
> > > > > the users. And every time you open a tab you notice the slowdown. Moving the
> > > > > compositing to the UI (or to a dedicated process as Carlos suggested) would
> > > > > use one gl context no matter how many tabs you have, fixing the problem.
> > > > > 
> > > > 
> > > > Do you recall how much memory that was? Cause the biggest memory issue I
> > > > recall was fixed 1.5 years ago in bug #164049. Yes, GL will always have some
> > > > overhead, but when taken as a percentage of the whole WebProcess consumption
> > > > I don't think you'd be able to mark that overhead as critical.
> > > 
> > > I don't remember, it was small for a single tab, but too much for many tabs.
> > > With current trunk loading about:blank in MiniBrowser I get:
> > > 
> > >  - Wayland no AC: UI: 17,3MB Web: 16,5MB
> > >  - Wayland AC: UI: 26,5MB Web: 22,3MB
> > >  - X11 no AC: UI: 12,6MB Web: 13,9MB
> > >  - X11 AC: UI: 14,5MB Web: 21,1MB
> > > 
> > 
> > How does this difference scale on a real-life page? Like I said, let's
> > specify the sites and do the measurements.
> 
> Using about:blank is just a way to set a minimum, any other website will use
> at least that.
> 

Yes, what I'm proposing is investigating what that additional amount of overhead is.

> > > > When moving composition to a single process, you don't take into account
> > > > that GL contexts are still needed for WebGL and GStreamer-GL. And nothing is
> > > > improved regarding painting, with Cairo all the memory still has to be
> > > > allocated just as before.
> > > 
> > > It's fine if only tabs currently using WebGL and GStreamer use additional gl
> > > contexts, the same way it's fine right now that some tabs have AC mode
> > > enabled.
> > > 
> > > > If the GL context creation overhead (in terms of memory and time) is a
> > > > problem, how is this not an even bigger problem for you when AC is entered
> > > > on demand, which can happen a bunch of times on a single page?
> > > 
> > > When a page enters and leaves AC, it's a single page doing so, I insist that
> > > the problem is having Ac enabled in all the pages.
> > 
> > IMO it's only a problem if you do no management of the idle pages. Or if you
> > go out and spawn about:blank pages for every tab.
> 
> That requires changes in WebKit much more complex than having AC on demand.
> 
> > > Note that when a page
> > > enters AC due to a condition change, an animation ro whatever, the page is
> > > already rendered so you are seeing the contents, not a white (or even black)
> > > page. Starting epiphany with a single or even a few tabs with AC enabled,
> > > was a bit slower but acceptable. But with some more tabs the thing was very
> > > noticeable. Not to mention resizing the window.
> > > 
> > 
> > Why is resizing the window an issue here? Is every web view being resized
> > when you're doing that?
> 
> Yes.
> 
> > I don't think you're rendering every loaded tab all the time, even if it's
> > not focused?
> 

Is this specific to GLX?

> No, painting is suspended, but other things are done, because otherwise when
> you switch to another tab you see flickering or even worse effects.
> 
> > > > > > But even then, with lots of tabs open, the large majority of memory is not
> > > > > > spent on the graphics pipeline, but other things like Web content and
> > > > > > caches. You should be looking into WebProcess management instead.
> > > > > 
> > > > > If we fix all those problems with cairo and WebKitGTK+ browsers are usable
> > > > > with AC always enabled I'm open to try again, but that's not the case right
> > > > > now, with our current code the amount of memory gl adds on top makes it
> > > > > impossible.
> > > > > 
> > > > 
> > > > How much is that amount of memory? What percentage is it compared to the
> > > > memory consumption of that whole WebProcess? Let's specify Web pages to
> > > > test, and produce massif profiles and memory mapping dumps for comparison.
> > > 
> > > It's not that much percentage for a single web process. If the overhead of
> > > cairo or any other thing is solved and makes this one insignificant, then
> > > I'm open to try again, but we need to fix those first.
> > > 
> > 
> > This just feels like from the memory consumption POV, we the graphics people
> > are being asked to produce a miracle to reduce the memory burden that
> > originates from spawning about:blank tabs.
> 
> No, that's why we want to have AC on demand, because we know that gl
> requires more memory and we can't do anything about it. I'm sure we can do
> improvements on the graphics side, but to be able to switch to always AC we
> will require more changes in other parts (process management, idle tabs,
> etc.)
> 
> > > > Anyway, my point is, why does Epiphany have to immediately spawn a
> > > > WebProcess for each tab when it's launched, when I haven't even activated
> > > > that tab? And why can't a WebProcess for a given tab be shut down after the
> > > > tab wasn't activated for a while? That's what I meant with 'WebProcess
> > > > management'.
> > > 
> > > We could make improvements in process management, but they are not easy at
> > > all. Any improvement there to should be done in WebKit, not in the browser
> > > side. There are things that browsers can do, though, for example epiphany
> > > delays the loads of tabs until they are activated, by using placeholder tabs
> > > consisting of about:blank with a title. But a bunch of about:blank pages was
> > > still a problem in terms of memory and startup times.
> > > 
> > 
> > Again, I'd really like to hear why this can't be done at the browser level,
> > or rather what still needs to be done at the WebKit level.
> 
> WebKit is the one spawning the processes, at the browser level we can only
> not create a web view to avoid the process from being launched. But the
> point is that we don't want to fix only epiphany, all WebKitGTK+ based
> applications should benefit from whatever we improve here.
> 

New WebProcess is only spawned when a load is triggered on a web view, not when the web view is created.

> > > As Michael suggested we also have the problem of drivers. To enable AC
> > > unconditionally we need a way to get detailed information from users having
> > > problems. I thought about adding about:gpu or whatever, to show information
> > > about the gpu, the driver, the gl context, the opengl version profile, the
> > > extensions available, etc. With the idea of using
> > > HardwareAccelerationManager.cpp to blacklist known buggy drivers.
> > > 
> > > Any change in this needs to be done at the very beginning of a release cycle.
> > 
> > OK, understandable.
> 
> It's clear that we can't switch to AC always *right now*, but we might by
> adopting any or several of the proposals made here. Some of them could be
> easy to try and some others are more long term goals. So, I propose to list
> and prioritize things we can do. For example:
> 
>  - Keep AC on demand, but never exit AC once entered for the same
> website/origin. I liked this idea, it's not a long term solution, but could
> be easily implemented and would avoid enter/leaves just when a tooltip is
> shown, for example.
> 
>  - Improve the memory consumption on the graphics side (cairo).
> 
>  - Add one process per origin process model.
> 
>  - Implement tab suspending.
> 
>  - Move the compositing to the UI or dedicated gpu process.
> 
>  - Make it possible to blacklist gpus, and add about:gpu to make it easier
> to collect the required info from users.
> 
> Any other idea? Note these tasks are not mutually exclusive, and some of
> them are blockers like the gpu blacklisting.

Delayed AC entry could help, especially with bugs like this one.

[Zan Dobersek]

(In reply to Michael Catanzaro from comment #50)
> www.gnome.org in Wayland:
> 
> AC mode: UI 39.4 MiB, web 156.3 MiB
> Non AC: UI 31.1 MiB, 129.8 MiB
> 
> Counting only the difference in web process memory usage, the difference
> would reach 1 GB more memory consumed at around 40 tabs.

Don't know if you tested with Epiphany, but given I can reproduce similar numbers with Epiphany 3.28, I'd like to point out that a very large proportion of consumed memory is allocated from the loaded Web extension.

[Zan Dobersek]

Created attachment 343045 [details]
Epiphany 3.28 WebKitWebProcess massif profile

Epiphany was launched via
$ WEBKIT_FORCE_COMPOSITING_MODE=1 Malloc=1 epiphany -i http://www.gnome.org

Quick sum of all the allocations coming from the extension quickly goes north of 50MB.

[Zan Dobersek]

Created attachment 343046 [details]
Epiphany 3.28 WebKitWebProcess massif profile

Similar Massif profile, but now with G_SLICE=always-malloc for completeness. It doesn't have a big impact on results though.

My point here is, if you're looking to optimize memory usage in WebProcess instances, this extension (I assume the ad blocker) is a very good place to start regardless of how much memory AC consumes in parallel.

[Adrian Perez]

(In reply to Zan Dobersek from comment #57)
> Created attachment 343046 [details]
> Epiphany 3.28 WebKitWebProcess massif profile
> 
> Similar Massif profile, but now with G_SLICE=always-malloc for completeness.
> It doesn't have a big impact on results though.
> 
> My point here is, if you're looking to optimize memory usage in WebProcess
> instances, this extension (I assume the ad blocker) is a very good place to
> start regardless of how much memory AC consumes in parallel.

Ouch. This is one more reason to try and enable content extensions,
which should be much better than the current adblocker present in
Epiphany. I'll try to get back to bug #167941 in the next days.

[Miguel Gomez]

(In reply to Miguel Gomez from comment #25)
> Created attachment 342736 [details]
> Patch

In the end this is not conflicting with Zan's refactor so I'll rebase and land this patch.

[Miguel Gomez]

Created attachment 343594 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 343594 [details]
Patch

Clearing flags on attachment: 343594

Committed r233193: <https://trac.webkit.org/changeset/233193>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.