RESOLVED FIXED 256873
[GTK] gsk_gl_command_queue_create_render_target: assertion failed (glCheckFramebufferStatus (GL_FRAMEBUFFER) == GL_FRAMEBUFFER_COMPLETE) when opening webkit://gpu
https://bugs.webkit.org/show_bug.cgi?id=256873
Summary [GTK] gsk_gl_command_queue_create_render_target: assertion failed (glCheckFra...
enometh
Reported 2023-05-16 21:02:23 PDT
I've seen this MiniBrowser crash on opening webkit://gpu with gtk4, but was informed it works with epiphany and gtk4 on fedora. I'm attaching the output of bt full, Maybe others have seen this or can suggest what might be different in my setup?
Attachments
gdb backtrace from Minibrowser webkit://gpu on GTK4 (20.27 KB, text/plain)
2023-05-17 09:10 PDT, enometh
no flags
enometh
Comment 1 2023-05-16 21:04:47 PDT
this was on webkit version 2.41.3 gtk-4.10.3
Michael Catanzaro
Comment 2 2023-05-17 05:16:54 PDT
(In reply to enometh from comment #0) > I'm attaching the output of bt full, You forgot to attach the backtrace.
enometh
Comment 3 2023-05-17 09:10:58 PDT
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)
Michael Catanzaro
Comment 4 2023-05-17 09:36:05 PDT
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.
Michael Catanzaro
Comment 5 2023-05-17 09:45:42 PDT
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
Michael Catanzaro
Comment 6 2023-05-17 09:50:41 PDT
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
enometh
Comment 7 2023-05-17 20:22:50 PDT
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?
enometh
Comment 8 2023-05-18 22:34:17 PDT
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?
Carlos Garcia Campos
Comment 9 2023-05-19 02:20:40 PDT
Carlos Garcia Campos
Comment 10 2023-05-19 02:21:18 PDT
I can't reproduce the crash, could you try the patch in the PR, please?
enometh
Comment 11 2023-05-20 09:42:42 PDT
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.
EWS
Comment 12 2023-05-21 22:31:30 PDT
Committed 264311@main (edc3fa95e515): <https://commits.webkit.org/264311@main> Reviewed commits have been landed. Closing PR #14063 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.