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 | ||
XoD
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 | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Michael Catanzaro
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
Can you tell us exactly which WebKitGTK version you are using?
XoD
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
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
(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
(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