Bug 306993 – REGRESSION(306485@main): [GTK] Crashes or bad rendering with compositing mode disabled or with hardware acceleration disabled and softGL.

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Carlos Alberto Lopez Perez]

There are several issues with 306485@main that causes crashes or bad renderings on WebKitGTK when not using the accelerated compositing mode.

Problems:

A) MiniBrowser Crash with env vars WEBKIT_DISABLE_DMABUF_RENDERER or WEBKIT_DISABLE_DMABUF_RENDERER

Enabling any of this two en vars will crash MiniBrowser

WEBKIT_DISABLE_COMPOSITING_MODE=1 Tools/Scripts/run-minibrowser --gtk
# crash

WEBKIT_DISABLE_DMABUF_RENDERER=1 Tools/Scripts/run-minibrowser --gtk
# crash



B) Bad rendering with WEBKIT_HARDWARE_ACCELERATION_POLICY_NEVER and softGL

To reproduce this do the following:

1) Apply this patch to MiniBrowser:

diff --git a/Tools/MiniBrowser/gtk/main.c b/Tools/MiniBrowser/gtk/main.c
index d3fbb968ee46..6fa773585ec5 100644
--- a/Tools/MiniBrowser/gtk/main.c
+++ b/Tools/MiniBrowser/gtk/main.c
@@ -1011,6 +1011,7 @@ int main(int argc, char *argv[])
     webkit_settings_set_enable_developer_extras(webkitSettings, TRUE);
     webkit_settings_set_enable_webgl(webkitSettings, TRUE);
     webkit_settings_set_enable_media_stream(webkitSettings, TRUE);
+    webkit_settings_set_hardware_acceleration_policy(webkitSettings, WEBKIT_HARDWARE_ACCELERATION_POLICY_NEVER);
 
     if (!addSettingsGroupToContext(context, webkitSettings))
         g_clear_object(&webkitSettings);


2) Build GTK Release
3) Run the minibrowser like this

LIBGL_ALWAYS_SOFTWARE=1 Tools/Scripts/run-minibrowser --gtk  https://www.meneame.net

Instead of rendering the website it renders some rectangles (note: i'm testing on X11). I see this:  https://people.igalia.com/clopez/bad_rendering_meneame_regression_306485.png

This bad rendering is also reproducible if you navigate a bit and go back and forward, but with this meneame website is 100% reproducible all the times (at least for me)

When the issue happens after pressing ongoing back and forth it prints lot of errors on stdout like this:

AcceleratedSurface was unable to construct a complete framebuffer
AcceleratedSurface was unable to construct a complete framebuffer


C) WebProcess crashes at termination

To reproduce this apply the same patch than B) (above) and run the minibrowser with softGL also

ulimit -c unlimited
LIBGL_ALWAYS_SOFTWARE=1 Tools/Scripts/run-minibrowser --gtk 

Then navigate a bit and you will see on the stdout of minibrowser this lines

WebKitWebProcess: ../src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
WebKitWebProcess: ../src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
WebKitWebProcess: ../src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.

And on coredumpctl you will see coredumps for WebKitWebProcess  when the WebProcess is closed to use a new one (due to PSON)

Another way to reproduce this is to launch the minibrowser in this URL and close it in just 1-2 seconds after the animation loads

LIBGL_ALWAYS_SOFTWARE=1 Tools/Scripts/run-minibrowser --gtk https://webglsamples.org/aquarium/aquarium.html

[Carlos Alberto Lopez Perez]

BTW, I double-checked that nothing of this happens if I revert 306485@main locally.

[Carlos Garcia Campos]

Pull request: https://github.com/WebKit/WebKit/pull/57933

[Carlos Garcia Campos]

(In reply to Carlos Alberto Lopez Perez from comment #0)
> There are several issues with 306485@main that causes crashes or bad
> renderings on WebKitGTK when not using the accelerated compositing mode.

Thanks for reporting!

> Problems:
> 
> A) MiniBrowser Crash with env vars WEBKIT_DISABLE_DMABUF_RENDERER or
> WEBKIT_DISABLE_DMABUF_RENDERER
> 
> Enabling any of this two en vars will crash MiniBrowser
> 
> WEBKIT_DISABLE_COMPOSITING_MODE=1 Tools/Scripts/run-minibrowser --gtk
> # crash
> 
> WEBKIT_DISABLE_DMABUF_RENDERER=1 Tools/Scripts/run-minibrowser --gtk
> # crash
> 

This should be fixed by PR 57933.

> 
> B) Bad rendering with WEBKIT_HARDWARE_ACCELERATION_POLICY_NEVER and softGL
> 
> To reproduce this do the following:
> 
> 1) Apply this patch to MiniBrowser:
> 
> diff --git a/Tools/MiniBrowser/gtk/main.c b/Tools/MiniBrowser/gtk/main.c
> index d3fbb968ee46..6fa773585ec5 100644
> --- a/Tools/MiniBrowser/gtk/main.c
> +++ b/Tools/MiniBrowser/gtk/main.c
> @@ -1011,6 +1011,7 @@ int main(int argc, char *argv[])
>      webkit_settings_set_enable_developer_extras(webkitSettings, TRUE);
>      webkit_settings_set_enable_webgl(webkitSettings, TRUE);
>      webkit_settings_set_enable_media_stream(webkitSettings, TRUE);
> +    webkit_settings_set_hardware_acceleration_policy(webkitSettings,
> WEBKIT_HARDWARE_ACCELERATION_POLICY_NEVER);
>  
>      if (!addSettingsGroupToContext(context, webkitSettings))
>          g_clear_object(&webkitSettings);

PR 57933 adds support for passing --hardware-acceleration-policy=always|never to MiniBrowser.

> 
> 2) Build GTK Release
> 3) Run the minibrowser like this
> 
> LIBGL_ALWAYS_SOFTWARE=1 Tools/Scripts/run-minibrowser --gtk 
> https://www.meneame.net
> 
> Instead of rendering the website it renders some rectangles (note: i'm
> testing on X11). I see this: 
> https://people.igalia.com/clopez/bad_rendering_meneame_regression_306485.png

I can't reproduce this with PR 57933 on wayland, I haven't tried X11, open a new report for this if it still happens on X11.

> This bad rendering is also reproducible if you navigate a bit and go back
> and forward, but with this meneame website is 100% reproducible all the
> times (at least for me)
> 
> When the issue happens after pressing ongoing back and forth it prints lot
> of errors on stdout like this:
> 
> AcceleratedSurface was unable to construct a complete framebuffer
> AcceleratedSurface was unable to construct a complete framebuffer
> 
> 
> C) WebProcess crashes at termination
> 
> To reproduce this apply the same patch than B) (above) and run the
> minibrowser with softGL also
> 
> ulimit -c unlimited
> LIBGL_ALWAYS_SOFTWARE=1 Tools/Scripts/run-minibrowser --gtk 
> 
> Then navigate a bit and you will see on the stdout of minibrowser this lines
> 
> WebKitWebProcess: ../src/dispatch_common.c:872: epoxy_get_proc_address:
> Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
> WebKitWebProcess: ../src/dispatch_common.c:872: epoxy_get_proc_address:
> Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
> WebKitWebProcess: ../src/dispatch_common.c:872: epoxy_get_proc_address:
> Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
> 
> And on coredumpctl you will see coredumps for WebKitWebProcess  when the
> WebProcess is closed to use a new one (due to PSON)
> 
> Another way to reproduce this is to launch the minibrowser in this URL and
> close it in just 1-2 seconds after the animation loads
> 
> LIBGL_ALWAYS_SOFTWARE=1 Tools/Scripts/run-minibrowser --gtk
> https://webglsamples.org/aquarium/aquarium.html

I think I fixed this crash already in https://commits.webkit.org/306709@main

[EWS]

Committed 306842@main (1050700930f6): <https://commits.webkit.org/306842@main>

Reviewed commits have been landed. Closing PR #57933 and removing active labels.