Inattaque glXMakeCurrent plante l'application C++

Question

D'habitude, je suis capable de résoudre presque toutes mes questions de programmation par moi-même, mais celui-ci m'étonne vraiment et je suppose que vous le trouverez aussi très intéressant. Je travaille donc sur une application OpenGL de bas niveau utilisant GLX et elle se bloque avec un défaut de segmentation. J'ai cassé le code jusqu'à cet exemple minimal:

#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; 
} 

Je compilez avec

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

J'utilise 64 bits Linux Mint 17,3 par la manière. Comme vous pouvez le voir, il n'y a rien de suspect - je veux dire que ça ne fait même rien, mais comme je l'ai dit, ça plante ... Le Segfault disparaît si je commente le glXMakeCurrent ce qui n'a absolument aucun sens, car ce n'est même pas atteint. Il ne plante pas non plus si je supprime l'instanciation de la chaîne. Échanger les instanciations ou les inclusions n'aide pas, il plante toujours.

Voici un GDB Backtrace:

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) 

et ma glxinfo sortie (sauf pour les extensions)

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) 

Je suis vraiment étonné par cela, parce que mon humble avis, il n'a absolument aucun sens. L'un de vous a-t-il une idée de ce que pourrait être le problème? Je pensais que certains appels auraient pu corrompre les classes VTable, mais dans cet exemple il n'y a même pas de classes. Ce n'est pas non plus un conflit 32-en-64-bit avec libGL.so. Lorsque je mets un std::cerr << "foo"; et (pour être sûr que ce ne soit pas nécessaire) au début de la fonction principale, je n'ai pas de sortie, donc cela semble être un problème avec le chargement de la librairie, mais je peux exécuter le code de opengl.org/wiki/Tutorial:_OpenGL_3.0_Context_Creation_(GLX), de sorte que le problème ne peut pas être la découverte de la bibliothèque ou la puce graphique étant dans un état défectueux ou à peu près (j'ai même redémarré ... une machine Linux ... voilà comment d'idées je suis)

Answer 1

en double de Segmentation Fault before main() when using glut, and std::string? La solution, il fonctionne pour moi aussi: forcer libpthread à lier, par exemple par

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

Encore l'un des problèmes les plus bizarres et illogiques que j'ai jamais rencontrés.