Sigil crashes with fatal OpenGL error

[Banjo]

My sigil is now crashing with the following OpenGL error.

Error info: Fatal: Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) 
Sigil version: 0.9.16
Runtime Qt: 5.12.6
Compiled Qt: 5.12.2
Platform: Linux

This happens when I open a valid epub book with Sigil. The Sigil window appears showing the contents of the book, and then it posts a dialog with the fatal error in it. The only option at that point is to close the dialog, and Sigil goes away.

I read online that this is caused by stale graphics drivers, but an update to my system a few minutes ago installed a new version of the Nvidia driver. The update did not fix the problem. As far as I can tell, all of my other graphics programs are running fine, before and after the update. Even Blender runs, and that goes straight into OpenGL.

This is probably a system problem or a QT problem rather than a sigil problem, but any pointers to where I can start looking would be appreciated.

Here is my system info:

System:    Host: BSKMageia Kernel: 5.5.9-desktop-1.mga7 x86_64 bits: 64 Desktop: KDE Plasma 5.15.4 
           Distro: Mageia 7 mga7 
Machine:   Type: Desktop Mobo: ASUSTeK model: P5G41T-M LX PLUS v: Rev X.0x serial: <root required> 
           BIOS: American Megatrends v: 0502 date: 10/21/2011 
CPU:       Dual Core: Intel Core2 Duo E7300 type: MCP speed: 1620 MHz 
Graphics:  Device-1: NVIDIA G94 [GeForce 9600 GT] driver: nvidia v: 340.108 
           Display: x11 server: Mageia X.org 1.20.7 driver: nvidia,v4l resolution: 1920x1080~60Hz 
           OpenGL: renderer: GeForce 9600 GT/PCIe/SSE2 v: 3.3.0 NVIDIA 340.108

Thanks,
Banjo

[KevinH]

One thing to note ... your older Sigil version was compiled against Qt 5.12.2 but you are currently running it with Qt 5.12.6. Would it be easy for you to try with Qt 5.12.2 again to see if the crashes? Or alternatively, upgrade and build a more recent version of Sigil built against that specific version of Qt.

There are also some opengl related Qt environment vars that might impact what you are seeing. Might want to check the Qt website for those.

[KevinH]

Here are some env var settings to try:

export QT_OPENGL="desktop"
Then try launching Sigil in that terminal

You could also try using ANGLE via

export QT_OPENGL="angle"
Then try opening Sigil in that terminal session.

and lastly you could try software opengl emulation

export QT_OPENGL="software"
Then try running Sigil from that terminal session.

Do any of these impact the error you are getting?

[KevinH]

From a google search... if your nvidea drivers are up to date, then this version of Qt can't find them (they may not be in your LD_LIBRARY_PATH etc).

If you know how you might be able to use ldd to try to find libGL and look to see where it is looking. Perhaps a strace or ptrace while starting up Sigil may help.

[Banjo]

Thanks for the quick response. Everything on the system is directly out of the distro repositories, so the theory is that it is all compatible. However, that doesn't mean that an update didn't break it. I cannot find any QT 5.12.2 libraries on the system. They must have been removed during the upgrades.

I tried the three QT_OPENGL settings, and they didn't fix the problem.

The Nvidia drivers on this system are strange. Every time a new kernel is issued, the system rebuilds the Nvidia drivers from source and inserts them into the kernel. That just happened today. How all that gets disseminated to things like QT is unknown to me.

Yesterday I built PageEdit from source to see how that works. I ran it standalone and it works fine. I don't think that the build is related to this problem.

Perhaps I will try to build one of the newer versions of Sigil from source and see if it works better. That will take me a while.

[DiapDealer]

I've seen that error on Windows a few times since we moved to WebEngine, but not for a long time now. They were all while the Windows installer was using Qt5.12.6 if I recall.

My research indicates that error almost always indicates a video driver problem/deficiency.

[Banjo]

That old computer is gradually failing. The on-board Intel graphics do not work at all any more. So I am stuck with the ancient Nvidia card and the associated drivers.

I think that just for grins I will attempt to build one of the newer versions of Sigil against the QT that I have and see if I can bring it back.

The last time I built Sigil from source it took quite a while because the RPM packages have different names than the ones mentioned in the instructions, so it was difficult to figure out the dependencies. So this could take a while. Having built PageEdit recently, I am a bit ahead of the game on the QT dependencies. The Python dependencies tend to be a black hole.

I will see what i can do to build from source and then report back. Thanks for the help.

[KevinH]

Found one similar bug report that reinstalling both libGL.so and libGLX.so fixed their issue. Might be worth a try.

[Banjo]

Update on my progress.

I downloaded the source for Sigil-1.2.1 and built it on my system. When I run it, the new version crashes with the same error as the old version.

$ sigil
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Warning: WebEngineContext used before QtWebEngine::initialize() or OpenGL context creation failed.
Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) 
Aborted (core dumped)

So it is not a dependency on the Qt version I am running. I built the new Sigil against the version on my system, 5.12.6.

Everywhere I read about this problem the answer is with misconfigured Nvidia drivers.

The odd thing is that I have other Qt apps running on my desktop with no problems. Which means that Qt can find the Nvidia drivers OK in that case.

LD_LIBRARY_PATH is not set to anything. I tried adding the Nvidia drivers to it.

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib64/nvidia-340"

That didn't help at all.

BTW, building Sigil on the Mageia system is a bit tricky because the development packages have different names than what are in the installation guide. Once I figured out which packages to install to satisfy the dependencies, the build went fine. For future reference, here are the ones I needed for Mageia:

lib64qt5webengine-devel
lib64qt5svg-devel
lib64qt5xmlpatterns-devel
lib64qt5help-devel to get Qt5LinguistTools
lib64python3-devel

I continue searching for the answer.

[DiapDealer]

There's a couple of error/warning messages related to libGL/OpenGL that I've not seen before. Hopefully they turn up some more info.

[DiapDealer]

Seems to me that hardware-based openGL support is insufficient, but the proper software-based openGL libraries cannot be found/loaded.

[Banjo]

The mesa drivers are installed on this system.

# locate libGL.so
/usr/lib/nvidia340/libGL.so.1
/usr/lib/nvidia340/libGL.so.340.108
/usr/lib64/libGL.so
/usr/lib64/libGL.so.1
/usr/lib64/libGL.so.1.2.0
/usr/lib64/mesa/libGL.so.1
/usr/lib64/mesa/libGL.so.1.2.0
/usr/lib64/nvidia340/libGL.so.1
/usr/lib64/nvidia340/libGL.so.340.108

However, if I dump out /etc/ld.so.cache, I don't see the mesa drivers included.

# ldconfig -p | grep -i gl.so
        libwayland-egl.so.1 (libc6,x86-64) => /lib64/libwayland-egl.so.1
        libwayland-egl.so (libc6,x86-64) => /lib64/libwayland-egl.so
        libftgl.so.2 (libc6,x86-64) => /lib64/libftgl.so.2
        libQt5OpenGL.so.5 (libc6,x86-64) => /lib64/libQt5OpenGL.so.5
        libQt5OpenGL.so (libc6,x86-64) => /lib64/libQt5OpenGL.so
        libQtOpenGL.so.4 (libc6,x86-64) => /lib64/libQtOpenGL.so.4
        libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia340/libGL.so.1
        libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib/nvidia340/libGL.so.1
        libGL.so (libc6,x86-64) => /lib64/libGL.so
        libEGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia340/libEGL.so.1
        libEGL.so.1 (libc6,x86-64) => /lib64/libEGL.so.1
        libEGL.so.1 (libc6) => /usr/lib/nvidia340/libEGL.so.1
        libEGL.so (libc6,x86-64) => /lib64/libEGL.so

I am so far over my head on this path.

Back to the books.

[DiapDealer]

It is my understanding that it's an either/or thing with the proprietary nvidia drivers and mesa. On some systems, the openGL portions of each may actually conflict.

See what the output of the following command is:

LIBGL_DEBUG=verbose glxinfo | grep -iE "opengl|^direct|^libgl"

That assumes the glxinfo binary is installed. Depending on the distro, it might be provided by the mesa package (or maybe mesa-utils). On my Arch system, it's provided by mesa-demos.

[Banjo]

OK. You are way over my head with this one. I have no idea what this means, but here is the output.

$ LIBGL_DEBUG=verbose glxinfo | grep -iE "opengl|^direct|^libgl"
direct rendering: Yes
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 9600 GT/PCIe/SSE2
OpenGL core profile version string: 3.3.0 NVIDIA 340.108
OpenGL core profile shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.3.0 NVIDIA 340.108
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 NVIDIA 340.108 340.108
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.00
OpenGL ES profile extensions:

[KevinH]

according to one post, moving or renaming the mesa versions of libGL did the trick. Might be worth a shot.