Bug 237535

Summary: [GTK] Crash at startup when glGetString(GL_VERSION) returns empty string
Product: WebKit Reporter: XoD <xoddark>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WORKSFORME    
Severity: Critical CC: aperez, bugs-noreply, mcatanzaro
Priority: P2    
Version: Other   
Hardware: PC   
OS: Linux   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=2061188

XoD
Reported 2022-03-07 08:48:11 PST
Since some day (with an update ?), application than use Webkit2gtk3.so crash at start. Application are Geary, Gnome-Web(Epiphany), Gnome-Builder It crash in WebKit::AcceleratedBackingStoreWayland::checkRequirements, and more precisely in GLContext::version() because ::glGetString(GL_VERSION) return an empty string, (or 0). But I don't understand why since the initialization of the GL context by EGL seems to have gone well. In any case, a context has been created . I don't know how to investigate more to understand and fix the problem. Related crash report : https://retrace.fedoraproject.org/faf/reports/361918/ And bug : https://bugzilla.redhat.com/show_bug.cgi?id=2061188 Setup: Fedora 35 up-to-date
Attachments
Michael Catanzaro
Comment 1 2022-03-07 11:08:31 PST
One more note from the downstream bug: """ I do additional debug (with gdb) : in tryInitializeEGL GLContext::createOffscreenContext seems to initialize correctly the context. eglContext->makeContextCurrent seems also work correctly. But call to GLContext::current()->version() always fail. I don't kow how to continue debug to have more informations. I have tried to step into ::glGetString(GL_VERSION), but gdb don't allow me to do this. """
Michael Catanzaro
Comment 2 2022-03-07 16:38:47 PST
Can you tell us exactly which WebKitGTK version you are using?
XoD
Comment 3 2022-03-08 01:03:57 PST
sure, dnf info say : Nom : webkit2gtk3 Version : 2.34.6 Publication : 1.fc35 Architecture : x86_64 Source : webkit2gtk3-2.34.6-1.fc35.src.rpm
XoD
Comment 4 2022-03-21 06:33:12 PDT
I don't know why, but the problem was caused by a local build of mesa (installed in ~/.local/). When I have removed it, problem was fixed. I let you decide, if it's useful to keep this bug to improve management of this type of problem. Thank you and sorry.
Adrian Perez
Comment 5 2022-03-21 06:49:15 PDT
(In reply to XoD from comment #4) > I don't know why, but the problem was caused by a local build of mesa > (installed in ~/.local/). > When I have removed it, problem was fixed. > > I let you decide, if it's useful to keep this bug to improve management of > this type of problem. Thanks for letting us now. I will close this bug as WORKSFORME because I couldn't reproduce it, and as you mention it does look like some issue on your system. If anybody else bumps into this again we can always reopen the bug later. > Thank you and sorry. No problem at all! =)
Michael Catanzaro
Comment 6 2022-03-21 07:08:47 PDT
(In reply to XoD from comment #4) > I don't know why, but the problem was caused by a local build of mesa > (installed in ~/.local/). For future reference, this is the sort of thing you should suspect when dealing with graphics issues. :P
Note You need to log in before you can comment on or make changes to this bug.