不可达的glxmakeccurrent导致c++应用程序崩溃

Unreachable glXMakeCurrent crashes c++ application

本文关键字：c++ 应用程序 崩溃 导致 glxmakeccurrent      更新时间：2023-10-16

通常我能自己解决几乎所有的编程问题，但这一个真的让我惊讶，我想你也会发现它很有趣。

所以我正在使用GLX开发一个低级OpenGL应用程序，它因分割错误而崩溃。我把代码分解成这个最小的例子:

#include <string>
#include <GL/glx.h>
int main(int argc, char** argv)
{
    Display* display = NULL;
    if(display)
        glXMakeCurrent(display, 0, 0);
    std::string title("Hello GLX");
    return 0;
}

我用

编译
g++ -g -o wtf wtf.cpp -lGL

我用的是64位Linux Mint 17.3。

正如你所看到的，没有什么可疑的-我的意思是它甚至什么都不做，但正如我所说的，它崩溃了…如果我注释掉glXMakeCurrent，段故障就消失了，这完全没有意义，因为它甚至没有达到。如果我删除字符串的实例化，它也不会崩溃。交换实例化或包含没有帮助，它仍然崩溃。

下面是一个GDB回溯:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff3deb291 in init () at dlerror.c:177
#2  0x00007ffff3deb6d7 in _dlerror_run (operate=operate@entry=0x7ffff3deb130 <dlsym_doit>, args=args@entry=0x7fffffffdc50)
    at dlerror.c:129
#3  0x00007ffff3deb198 in __dlsym (handle=<optimized out>, name=<optimized out>) at dlsym.c:70
#4  0x00007ffff7b4ee1e in ?? () from /usr/lib/nvidia-352/libGL.so.1
#5  0x00007ffff7af9b47 in ?? () from /usr/lib/nvidia-352/libGL.so.1
#6  0x00007ffff7dea0cd in call_init (l=0x7ffff7ff94c0, argc=argc@entry=1, argv=argv@entry=0x7fffffffdda8, 
    env=env@entry=0x7fffffffddb8) at dl-init.c:64
#7  0x00007ffff7dea1f3 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>)
    at dl-init.c:36
#8  _dl_init (main_map=0x7ffff7ffe1c8, argc=1, argv=0x7fffffffdda8, env=0x7fffffffddb8) at dl-init.c:126
#9  0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ?? ()
#11 0x00007fffffffe101 in ?? ()
#12 0x0000000000000000 in ?? ()
(gdb)

和我的glxinfo输出(除了扩展)

name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
...
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
...
GLX version: 1.4
...
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 560 Ti/PCIe/SSE2
OpenGL core profile version string: 4.3.0 NVIDIA 352.63
OpenGL core profile shading language version string: 4.30 NVIDIA via Cg compiler
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
...
OpenGL version string: 4.5.0 NVIDIA 352.63
OpenGL shading language version string: 4.50 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)

我真的很惊讶，因为我觉得这完全没有意义。你们有人知道问题出在哪里吗?我在想，一些调用可能已经损坏了类VTable，但在这个例子中，甚至没有类。它也不会与libgl发生32-vs-64-bit的冲突。

当我把std::cerr << "foo";和std::cerr.flush();(可以肯定的是，虽然它不应该是必要的)在主函数的开始，我没有得到输出，所以它似乎是加载库的问题，但我可以从opengl.org/wiki/Tutorial:_OpenGL_3.0_Context_Creation_(GLX运行代码)，所以问题不能是库或图形芯片处于某种故障状态的发现(我甚至重新启动…Linux机器…

在使用glut和std::string时，在main()之前重复分段错误?这里的解决方法也适用于我:强制libpthread被链接，例如通过

export LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0
./wtf

这仍然是我遇到过的最奇怪、最不合逻辑的问题之一。

相关文章：