[RESOLVED] Sigil crashes with fatal OpenGL error

[banjo]

I am running Mageia 7. Sigil does not run. It throws a fatal error and crashes.

Code: Select all

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

The Sigil developers and I have tracked down the problem and have a workaround to get Sigil to run. The thread on the Sigil forum can be found here:

https://www.mobileread.com/forums/showthread.php?t=328605

The workaround is to edit the Sigil startup script, /usr/bin/sigil and fix an environment variable that is pointing to an incorrect Qt library location.

The Sigil cmake calls qmake to configure the makefiles for Sigil. Sigil uses a startup script called /usr/bin/sigil which sets an environment variable, QTLIB_DIR="/usr/lib64" which is incorrect. The correct location for the active Qt is /usr/lib64/qt5. Hence Sigil cannot find QT. The error is made in the call to qmake

Code: Select all

$ qmake -query QT_INSTALL_LIBS
/usr/lib64


While we have tracked down the cause of this crash, I do not want to mark this problem solved yet because the underlying cause of the crash might have a wider impact.

The incorrect reporting of qmake of the location of the Qt library may impact other builds as well. That is why I do not want to mark this solved yet, just because we have fixed it for Sigil.

Could someone please install Sigil and attempt to run it to confirm that the problem exists on platforms other than mine?

If that is the case, I will post a bug on bugzilla to see if the package manager can rebuild Sigil to correct the problem, or maybe boost the problem upstream for Qt folks to fix.

My system info:

Code: Select all

$ inxi -b
System:    Host: BSKMageia Kernel: 5.5.15-desktop-3.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: 2545 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
(_)=='=~

[doktor5000]

When should sigil crash, directly after starting? Because it starts just fine here ...

[banjo]

It crashed immediately on startup. I could not get it running at all.

I am wondering if Qt on my system got moved around over the months. I am running Cauldron on it, but now that Mageia 7 is out, it should be an equivalent system, correct? I don't want to blow this up out of proportion if it is happening because my system is somehow set up different than a clean install.

On your system, is Qt in /usr/lib64, or /usr/lib64/qt5? Which does the /usr/bin/sigil script point to?

Here is where qt is in /usr/lib64 on my system

Code: Select all

$ ls /usr/lib64 | grep -i qt

---- snipped out lots of stuff ------

libtelepathy-logger-qt.so.0.9.80.0*
libtelepathy-logger-qt.so.5@
libtelepathy-qt5-service.so.0@
libtelepathy-qt5-service.so.0.0.9.7*
libtelepathy-qt5.so.0@
libtelepathy-qt5.so.0.0.9.7*
qca-qt5/
qt3/
qt4/
qt5/
qtcreator/


I have three versions of qt in three different subfolders in /usr/lib64

Is that the normal location?

Thanks

[doktor5000]

The exact error message that it produced when crashing is the one in your first post? That sounds more like an issue with the OpenGL / graphics driver setup on your box, not with the Qt libraries themselves.
Can you run any other Qt or OpenGL application, or do they all crash with the same error message ?

If you were running cauldron, and never switched over to the Mageia 7 repositories, then you're still running cauldron I'd say.

Qt has been below /usr/lib64/qt5 since quite some time. /usr/bin/sigil points to /usr/lib64 for QTLIB_DIR.
Although reading the thread you linked to, could it be that your issue stems from the fact that you compiled sigil yourself, and I'm using the version from the Mageia repositories ?

[banjo]

I copied the error message out of the bash script that I attempted to run Sigil in. That was the entire output from the program. I ran strace on it as well, and it barfed with the same error.

Code: Select all

------ snip out tons of stuff ------

writev(3, [{iov_base="\231\6\2\0s\1\0\10", iov_len=8}], 1) = 8
futex(0x1a0e3e8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1a0e3e8, FUTEX_WAKE_PRIVATE, 1) = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="+\30\1\0", iov_len=4}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 4
futex(0x1a0e3e8, FUTEX_WAKE_PRIVATE, 1) = 1
write(2, "Failed to create OpenGL context "..., 397Failed 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)
) = 397
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
getpid()                                = 30609
gettid()                                = 30609
tgkill(30609, 30609, SIGABRT)           = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=30609, si_uid=1000} ---
+++ killed by SIGABRT (core dumped) +++


I first saw the crash on the version from the repository. One of the suggestions from the Sigil developers was to try building the newer version from source, which I did. Both versions crashed with the same error.

I also thought that it was an OpenGL problem, which sent me down a rabbit hole for a few days. I have many applications running on Qt, two of them I wrote myself. I can run Blender as well, which I understand goes straight to OpenGL for the entire interface. It was a puzzle that only Sigil was having a problem with OpenGL.

I also tried to run Sigil in gdb, and it ran. So somehow gdb found the libraries where the script could not.

It seems strange to me that yours will run with the QTLIB_DIR pointing to /usr/lib64 and mine would not. Is it possible that Sigil is doing a search and finding one of the older Qt installations on my computer and then throwing the error from there? I do have qt3, qt4, and qt5 on there. It must be doing some kind of search for Qt if it runs on your computer with the same settings.

FWIW I had nothing in my LD_LIBRARY_PATH variable.

And yes, I did not switch over the Mageia 7 repositories. That computer is my experimental setup, so it is unclean. I have not finished switching my main computer back from Mint to Mageia 7 yet so I don't have that platform yet to compare.

I might go fool around with it some more to see if I can puzzle out what is actually happening. Maybe I will move the qt3 and qt4 directories out of the way and see if it can find qt5.

Thanks for the ideas.

[doktor5000]

Maybe you should first try to reproduce this on a fresh Mageia 7 installation? Although I don't see the immediate need for that, as you already have a workaround ...

[banjo]

You are right that I should probably reformat the disk and start over. There is actually an old Mageia 6 on the computer as well. I haven't booted that for months. I brought this old computer out of retirement to run Cauldron and see what kind of trouble I could get into. I think I want to do the same when Mageia 8 fires up.

At this point, I am not trying to get Sigil to run. I am trying to understand how all of this hangs together. It is a puzzle more than a problem.

If Sigil runs OK on your system, and nobody else is complaining about it, then it is probably something in my system that is messed up. I will contact the Sigil developers and let them know not to worry about it.

Thanks

[doktor5000]

I will contact the Sigil developers and let them know not to worry about it.

As they already suspected in the forum thread, it's more of an issue with the graphics driver and the interaction with libGL, this can sometimes happen after driver updates.
One of our QA team members also noticed such an issue when testing a sigil update, this was also with nvidia driver: https://bugs.mageia.org/show_bug.cgi?id=25290#c3

[banjo]

I put the script /usr/bin/sigil back to its original content to make Sigil crash again so I can fool around with it and see what I can find out. I have had problems on my system with the Nvidia drivers before, but those mostly turned out to be mistakes made by me during installation. Recently they have been running fine, and I am not seeing any problems with any other applications.

Sigil does report an OpenGL error, but then when I explicitly point to the /usr/lib64/qt5 directory in the Sigil script, the problem goes away. I don't know what that means. One of the Sigil developers suggested that I run the command.

Code: Select all

update-alternatives --config qt5

"Alternatives" is another subsystem that I know nothing about, so I am back to the books. I ran the command, but it appeared to have no effect at all.

[doktor5000]

"Alternatives" is another subsystem that I know nothing about, so I am back to the books. I ran the command, but it appeared to have no effect at all.

That is because qt5 is not configured below the alternatives systems.

alternatives comes from Debian, and it's a mechanism to configure one approach if there are multiple major/minor versions of a given program/facility.

As an example, you can have java6, java7, java8 installed in parallel, and you can switch between those back and forth via alternatives --config java
Although this also requires the packager or upstream developers to prepare all those alternatives configurations and test if they're working.
It's also not only one configuration per program, but you also need the alternatives system to point to the particular configuration for e.g. a given java version, the ControlPanel, you need to switch the java browser plugin etc.

But in the most basic form you would have e.g. /usr/bin/java which would point to /etc/alternatives/java which could then be switched around to point to the actual java6, java7 or java8 binary.

You can have a look below /etc/alternatives to see what it covers.

[banjo]

Here is another interesting tidbit. Out of curiosity, I edited the /usr/bin/sigil script, which is the one from the repository, and I commented out QTLIB_DIR environment variable.

Code: Select all

#!/usr/bin/sh

# Entry point for Sigil on Unix systems.
# Adds linked Qt's lib directory to the LD_LIBRARY_PATH

#QTLIB_DIR="/usr/lib64"
SIGIL_BIN_DIR="/usr/lib64/sigil"

if [ -z "$LD_LIBRARY_PATH" ]; then
  LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$QTLIB_DIR"
else
  LD_LIBRARY_PATH="$SIGIL_BIN_DIR:$QTLIB_DIR:$LD_LIBRARY_PATH"
fi

# Create an environment var for the Sigil share directory location.
if [ -z "$SIGIL_SHARE_PREFIX" ]; then
  SIGIL_SHARE_PREFIX="/usr"
  export SIGIL_SHARE_PREFIX
fi

# Not really needed anymore but left in for fringe cases
#if [ -z "$SIGIL_EXTRA_ROOT" ]; then
#  SIGIL_EXTRA_ROOT="/usr/share/sigil"
#  export SIGIL_EXTRA_ROOT
#fi

export LD_LIBRARY_PATH

exec /usr/lib64/sigil/sigil "$@"



After that, Sigil runs fine. Not sure how it finds the default Qt libraries, but they work fine without the misdirection added to the LD_LIBRARY_PATH by QTLIB_DIR.

[banjo]

After further research and discussion with the Sigil development team, we decided that this problem is most likely being caused by some sort of mis-configuration of my system. It is not clear exactly what is causing it to happen, but it does not appear to be a problem on a clean installation of Mageia 7, and nobody else is reporting the issue.

Hence, no further action is indicated at this time, and I am marking it [RESOLVED].

Banjo
(_)=='=~