Bug#912925: glx-diversions: should divert libGL.so when other libraries are diverted to NVIDIA as pyqt5 breaks otherwise
On Tue, Nov 06, 2018 at 05:16:29PM +0100, Andreas Beckmann wrote: > > Another thing I've thought of doing is wrapping the dlopen library > > call to trace all calls to hopefully locate the source of the issue. > > > > But I still don't understand why you would not divert libGL.so when > > libGL.so.1 is being diverted - it doesn't make any sense to me. > > We are diverting it (otherwise it would be a dangling symlink) - we just > set the alternative unconditionally to the diverted one because we don't > want anything to get linked against the proprietary libraries at compile > time. Dear Andreas and Luca, Thanks for that explanation - it makes sense now. And I've managed to locate the bug in Qt at long last!! Just testing my proposed patch and then I'll submit a bug report against the correct package Best wishes, Julian
Bug#912925: glx-diversions: should divert libGL.so when other libraries are diverted to NVIDIA as pyqt5 breaks otherwise
On 2018-11-06 14:29, Julian Gilbey wrote: > On Mon, Nov 05, 2018 at 11:03:11PM +0100, Andreas Beckmann wrote: >> Does your testcase run under bumblebee? > > I don't know; I could try when I'm next at my desktop. I don't have > bumblebee installed (it seems to be intended for laptops). Well, you need a laptop with optimus for this, and I would expect your test case to break there, because optirun works with setting LD_LIBRARY_PATH to make the accelerated libraries (libGL.so.1 and friends) found by the programs run under optirun. That would probably result in the MESA libGL.so being dlopened. > Another thing I've thought of doing is wrapping the dlopen library > call to trace all calls to hopefully locate the source of the issue. > > But I still don't understand why you would not divert libGL.so when > libGL.so.1 is being diverted - it doesn't make any sense to me. We are diverting it (otherwise it would be a dangling symlink) - we just set the alternative unconditionally to the diverted one because we don't want anything to get linked against the proprietary libraries at compile time. Andreas
Bug#912925: glx-diversions: should divert libGL.so when other libraries are diverted to NVIDIA as pyqt5 breaks otherwise
On Tue, 2018-11-06 at 13:29 +, Julian Gilbey wrote: > On Mon, Nov 05, 2018 at 11:03:11PM +0100, Andreas Beckmann wrote: > > > By this argument, surely there should not be a libGL.so on the > > > system > > > at all? > > > > The .so file is for use by the linker. Not for runtime. > > Dear Andreas, > > Thanks for the speedy response! Ah, I hadn't realised > this. That > makes some sense. > > > > And it also does not address the serious issue that libGL.so > > > points to a different library from libGL.so.1. > > > > > > The discussions online show that this is an issue which has been > > > around for years. The solution is simple. > > > > Does your testcase run under bumblebee? > > I don't know; I could try when I'm next at my desktop. I don't have > bumblebee installed (it seems to be intended for laptops). > > Another thing I've thought of doing is wrapping the dlopen library > call to trace all calls to hopefully locate the source of the issue. > > But I still don't understand why you would not divert libGL.so when > libGL.so.1 is being diverted - it doesn't make any sense to me. > > Best wishes, > > Julian https://salsa.debian.org/nvidia-team/glx-alternatives/blob/master/debian/glx-diversions.README.Debian#L89 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#912925: glx-diversions: should divert libGL.so when other libraries are diverted to NVIDIA as pyqt5 breaks otherwise
On Mon, Nov 05, 2018 at 11:03:11PM +0100, Andreas Beckmann wrote: > > By this argument, surely there should not be a libGL.so on the system > > at all? > > The .so file is for use by the linker. Not for runtime. Dear Andreas, Thanks for the speedy response! Ah, I hadn't realised this. That makes some sense. > > And it also does not address the serious issue that libGL.so > > points to a different library from libGL.so.1. > > > > The discussions online show that this is an issue which has been > > around for years. The solution is simple. > > Does your testcase run under bumblebee? I don't know; I could try when I'm next at my desktop. I don't have bumblebee installed (it seems to be intended for laptops). Another thing I've thought of doing is wrapping the dlopen library call to trace all calls to hopefully locate the source of the issue. But I still don't understand why you would not divert libGL.so when libGL.so.1 is being diverted - it doesn't make any sense to me. Best wishes, Julian
Bug#912925: glx-diversions: should divert libGL.so when other libraries are diverted to NVIDIA as pyqt5 breaks otherwise
On 2018-11-05 13:45, Julian Gilbey wrote: > On Mon, Nov 05, 2018 at 10:43:44AM +0100, Andreas Beckmann wrote: >> Control: tag -1 wontfix >> >> On 2018-11-05 01:17, Julian Gilbey wrote: >>> So the pragmatic way to fix it would be to symlink libGL.so to the >>> NVIDIA libGL.so... (and presumably the other related .so libraries) >>> when glx-diversions is used. Because having libGL.so.1 pointing to >>> one version of the library and libGL.so pointing to an incompatible >>> version is causing this crash. >>> >>> Please could you therefore modify glx-diversions to ensure that the >>> unversioned libGL.so points to the same location as the versioned >>> libGL.so.1 (and the others too: libEGL.so, libGLESv1_CM.so and >>> libGLESv2.so). >> >> Stuff that dlopens the .so files is broken. They should dlopen the .so.1 >> (or thatever the soversion is). > > By this argument, surely there should not be a libGL.so on the system > at all? The .so file is for use by the linker. Not for runtime. > And it also does not address the serious issue that libGL.so > points to a different library from libGL.so.1. > > The discussions online show that this is an issue which has been > around for years. The solution is simple. Does your testcase run under bumblebee? Andreas
Bug#912925: glx-diversions: should divert libGL.so when other libraries are diverted to NVIDIA as pyqt5 breaks otherwise
On Mon, Nov 05, 2018 at 10:43:44AM +0100, Andreas Beckmann wrote: > Control: tag -1 wontfix > > On 2018-11-05 01:17, Julian Gilbey wrote: > > So the pragmatic way to fix it would be to symlink libGL.so to the > > NVIDIA libGL.so... (and presumably the other related .so libraries) > > when glx-diversions is used. Because having libGL.so.1 pointing to > > one version of the library and libGL.so pointing to an incompatible > > version is causing this crash. > > > > Please could you therefore modify glx-diversions to ensure that the > > unversioned libGL.so points to the same location as the versioned > > libGL.so.1 (and the others too: libEGL.so, libGLESv1_CM.so and > > libGLESv2.so). > > Stuff that dlopens the .so files is broken. They should dlopen the .so.1 > (or thatever the soversion is). By this argument, surely there should not be a libGL.so on the system at all? And it also does not address the serious issue that libGL.so points to a different library from libGL.so.1. The discussions online show that this is an issue which has been around for years. The solution is simple. Best wishes, Julian
Bug#912925: glx-diversions: should divert libGL.so when other libraries are diverted to NVIDIA as pyqt5 breaks otherwise
Control: tag -1 wontfix On 2018-11-05 01:17, Julian Gilbey wrote: > So the pragmatic way to fix it would be to symlink libGL.so to the > NVIDIA libGL.so... (and presumably the other related .so libraries) > when glx-diversions is used. Because having libGL.so.1 pointing to > one version of the library and libGL.so pointing to an incompatible > version is causing this crash. > > Please could you therefore modify glx-diversions to ensure that the > unversioned libGL.so points to the same location as the versioned > libGL.so.1 (and the others too: libEGL.so, libGLESv1_CM.so and > libGLESv2.so). Stuff that dlopens the .so files is broken. They should dlopen the .so.1 (or thatever the soversion is). Andreas
Bug#912925: glx-diversions: should divert libGL.so when other libraries are diverted to NVIDIA as pyqt5 breaks otherwise
Package: glx-diversions
Version: 0.8.8
Severity: important
Hi!
I have just spent 2+ days trying to track down the source of this bug,
without much success.
When running the following PyQt5 code, it bombs:
#!/usr/bin/python3
import sys
# from OpenGL import GL
from PyQt5.QtCore import QUrl
from PyQt5.QtWidgets import QApplication
from PyQt5.QtWebEngineWidgets import QWebEngineView
app = QApplication(sys.argv)
wv = QWebEngineView()
wv.load(QUrl('about:blank'))
wv.show()
app.exec_()
Here is the terminal output:
erdos:/tmp $ ./testqt.py
[1105/000408.477830:WARNING:stack_trace_posix.cc(699)] Failed to open file:
/tmp/.glj5nVFA (deleted)
Error: No such file or directory
[8683:8706:1105/000408.616185:ERROR:gl_surface_glx_qt.cpp(186)]
glXCreatePbuffer failed.
Received signal 11 SEGV_MAPERR
#0 0x7fb738ce7b9e
#1 0x7fb738ce7cb0
#2 0x7fb738ce82e7
#3 0x7fb74622c8e0
#4 0x7fb73775e07d
#5 0x7fb737746ec0
#6 0x7fb7396336ed
#7 0x7fb737ac3cfb
#8 0x7fb737ac5497
#9 0x7fb7398f36e5
#10 0x7fb73b094341
#11 0x7fb738d4ccc5
#12 0x7fb738d48631
#13 0x7fb746221f2a start_thread
#14 0x7fb745d59edf clone
r8: 0002 r9: r10: r11:
r12: 7fb6e37fd610 r13: 7fb6e37fd8d0 r14: 7fb6e37fd820 r15:
7fb73775dfd0
di: si: 00d8e150 bp: 7fb6e37fd5f0 bx:
7fb6c80030b0
dx: 00f5 ax: 7fb73d334680 cx: 7fb6e37fd410 sp:
7fb6e37fd410
ip: 7fb73775e07d efl: 00010206 cgf: 002b0033 erf:
0004
trp: 000e msk: cr2:
[end of stack trace]
Calling _exit(1). Core file will not be generated.
erdos:/tmp $
There is some discussion of this bug here:
https://bugreports.qt.io/browse/QTBUG-71488
If the commented line (from OpenGL import GL) is uncommented, the code
works fine.
At some point, some piece of code is loading libGL.so. I don't know
where this is happening, and I have completely failed to track it
down.
However, if the libGL.so symlink is made to point to the NVIDIA
library, then all works nicely.
I appreciate that in an ideal world, nothing would ever dlopen() an
unversioned libGL.so, but something, somewhere is doing so. I also
don't know why loading OpenGL should help fix this bizarre bug. I
have hunted and hunted for the source of the dlopen("libGL.so") (it's
definitely happening - I ran strace and saw this library being
opened), but failed miserably.
A kludge to fix it is to always load OpenGL in PyQt5 scripts, but that
is ugly. A nice way to fix it would be to locate the source of the
code which loads this. But that is proving utterly horrendous.
So the pragmatic way to fix it would be to symlink libGL.so to the
NVIDIA libGL.so... (and presumably the other related .so libraries)
when glx-diversions is used. Because having libGL.so.1 pointing to
one version of the library and libGL.so pointing to an incompatible
version is causing this crash.
Please could you therefore modify glx-diversions to ensure that the
unversioned libGL.so points to the same location as the versioned
libGL.so.1 (and the others too: libEGL.so, libGLESv1_CM.so and
libGLESv2.so).
Best wishes,
Julian
-- Package-specific info:
Diversions:
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.0.0 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.0.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.7.0 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.7.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of
