Bug 237535

Summary:	[GTK] Crash at startup when glGetString(GL_VERSION) returns empty string
Product:	WebKit	Reporter:	XoD <xoddark>
Component:	WebKitGTK	Assignee:	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

Description XoD 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

Comment 1 Michael Catanzaro 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.
"""

Comment 2 Michael Catanzaro 2022-03-07 16:38:47 PST

Can you tell us exactly which WebKitGTK version you are using?

Comment 3 XoD 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

Comment 4 XoD 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.

Comment 5 Adrian Perez 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! =)

Comment 6 Michael Catanzaro 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