On Fri, Jun 26, 2020 at 09:30:14PM +0300, Dmitry Shachnev wrote: > Some more information on this: it looks like dlopen'ing libGLX_mesa.so.0 > returns NULL (src/GLX/libglxmapping.c:430). > > LD_PRELOAD'ing that library helps. Adding the following two lines to top > of web_engine_initialize.py also helps: > > import ctypes > ctypes.CDLL('libGLX_mesa.so.0', ctypes.RTLD_GLOBAL) > > I can't say why dlopen fails without that, though.
Some more information on this. I remembered that there is dlerror function, and checked its output: $ gdb python3 (gdb) r ./test.py [...] (gdb) b libglxmapping.c:432 Breakpoint 1 at 0xfffff54f5f08: file ../src/GLX/libglxmapping.c, line 432. (gdb) r [...] Thread 1 "python3" hit Breakpoint 1, __glXLookupVendorByName (vendorName=<optimized out>) at ../src/GLX/libglxmapping.c:432 (gdb) p vendor->dlhandle $1 = (void *) 0x0 (gdb) p (char *)dlerror() $2 = 0xc54f60 "/usr/lib/aarch64-linux-gnu/libglapi.so.0: cannot allocate memory in static TLS block" So this is the real reason for this failure. I have searched the internet and found a couple of bug reports with a similar problem: - https://github.com/opencv/opencv/issues/14884 - https://bugzilla.redhat.com/show_bug.cgi?id=1722181 The last link mentions a glibc patch from ARM that is currently under review: https://sourceware.org/pipermail/libc-alpha/2020-May/114247.html Unfortunately my knowledge of library loading process is little. I am CCing glibc and mesa maintainers: maybe they can tell more about this issue? Finally, a very short Python reproducer for this bug (needs libqt5webengine5): #!/usr/bin/python3 import ctypes ctypes.CDLL("libQt5WebEngine.so.5") ctypes.CDLL("libglapi.so.0") fails with: Traceback (most recent call last): File "./test.py", line 4, in <module> ctypes.CDLL("libglapi.so.0") File "/usr/lib/python3.8/ctypes/__init__.py", line 373, in __init__ self._handle = _dlopen(self._name, mode) OSError: /usr/lib/aarch64-linux-gnu/libglapi.so.0: cannot allocate memory in static TLS block -- Dmitry Shachnev
Description: PGP signature