| Summary: | [GTK] gsk_gl_command_queue_create_render_target: assertion failed (glCheckFramebufferStatus (GL_FRAMEBUFFER) == GL_FRAMEBUFFER_COMPLETE) when opening webkit://gpu | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | enometh | ||||
| Component: | WebKitGTK | Assignee: | Carlos Garcia Campos <cgarcia> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | bugs-noreply, mcatanzaro, otte | ||||
| Priority: | P2 | ||||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
enometh
2023-05-16 21:02:23 PDT
this was on webkit version 2.41.3 gtk-4.10.3 (In reply to enometh from comment #0) > I'm attaching the output of bt full, You forgot to attach the backtrace. Created attachment 466383 [details]
gdb backtrace from Minibrowser webkit://gpu on GTK4
(sorry, apparently my connection dropped the first time I uploaded the file, but bugzilla detected that definitely asked me to attach it again when i logged in again, and I did. I assumed it worked, but it didn't)
This bug is https://gitlab.gnome.org/GNOME/gtk/-/issues/5392 which is supposed to be already fixed in the version of GTK that you are using. O_O I'll ping Benjamin. Here is our feedback:
> yeah, not surprised as long as webkit randomly uses GL without GTK involvement
>
> might be a case of the user using GLX and webkit deciding on EGL or vice versa
>
> the only fix is to not do that, make them clear_current() each other's current contexts or implement webkit's GL context on top of GdkGLContext
This looks like
I was going to say "This looks like we're doing something wrong with OpenGL" but decided not to, since that's obvious. Then I forgot to delete the first half of my sentence.
More from Benjamin:
> well, the problem here is webkit taking over GL in the UI process and confusing GTK
hmm a similar crash occurs on 2.41.1 even with gtk3. I passed -DENABLE_GLES2=on explicitly to cmake, which results in a cmakeconfig.h with ``` #define ENABLE_GLES2 1 #define USE_OPENGL 0 #define USE_OPENGL_ES 1 #define USE_OPENGL_OR_ES 1 ``` What combination of options avoids such a crash? I tried the same webkit with epiphany master from a few days ago. Both with GDK_BACKEND x11 and wayland. The crash occurs when I start it from the command line arg webkit://gpu However if I load another webpage first and enter webkit://gpu through the location input bar, it does not crash and I get a valid page with all the fingerprinting info It may be possible to see what epiphany is doing right with the GL stuff that fixes it? Pull request: https://github.com/WebKit/WebKit/pull/14063 I can't reproduce the crash, could you try the patch in the PR, please? I got around to compiling 2.41.4. I don't see the webkit://gpu crashes on gtk3 I saw before. With gtk4 On X11 if I do GDK_DEBUG=gl-egl MiniBrowser webkit://gpu there is no crash. Otherwise there is a crash. After applying this patch from commit 2b7bd3f23 (I think I've doing it correctly) the situation is the same. Committed 264311@main (edc3fa95e515): <https://commits.webkit.org/264311@main> Reviewed commits have been landed. Closing PR #14063 and removing active labels. |