c++ - segmentacion - ¿Falla de segmentación antes de main() cuando se usa glut y std:: string?

segmentacion primaria

Question

En Ubuntu 14.04 LTS de 64 bits, estoy tratando de compilar un programa simple de OpenGL que usa exceso. Estoy obteniendo una falla de segmentación (SIGSEV) antes de que cualquier línea de código se ejecute en main; incluso en un programa de prueba muy simplificado. Que podria causar esto?

Mi línea de comando:

g ++ -Wall -g main.cpp -lglut -lGL -lGLU -o principal

Mi caso de prueba simple:

#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glut.h>
#include <string>
#include <cstdio>
int main(int argc, char** argv){
printf("Started/n");
std::string dummy = "hello";
glutInit(&argc, argv);
return 0;
}

Cuando ejecuto el programa, el printf al principio de main no llega a ejecutarse antes de segfault. Bajo GDB, obtengo esta traza posterior después de que segfault

#0 0x0000000000000000 in ?? ()
#1 0x00007ffff3488291 in init () at dlerror.c:177
#2 0x00007ffff34886d7 in _dlerror_run (operate=operate@entry=0x7ffff3488130 <dlsym_doit>, args=args@entry=0x7fffffffddf0) at dlerror.c:129
#3 0x00007ffff3488198 in __dlsym (handle=<optimized out>, name=<optimized out>) at dlsym.c:70
#4 0x00007ffff702628e in ?? () from /usr/lib/nvidia-352/libGL.so.1
#5 0x00007ffff6fd1aa7 in ?? () from /usr/lib/nvidia-352/libGL.so.1
#6 0x00007ffff7dea0fd in call_init (l=0x7ffff7fd39c8, argc=argc@entry=1, argv=argv@entry=0x7fffffffdf48, env=env@entry=0x7fffffffdf58) at dl-init.c:64
#7 0x00007ffff7dea223 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=0x7fffffffdf48, env=0x7fffffffdf58) at dl-init.c:126
#9 0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#10 0x0000000000000001 in ?? ()
#11 0x00007fffffffe2ba in ?? ()
#12 0x0000000000000000 in ?? ()

Y aquí está el kicker. Si hago un comentario sobre la línea gluInit o la línea ficticia std :: string, el programa compila y funciona perfectamente. Hasta que noté esto, asumí que había algo mal con mi GLUT (aunque he probado el programa original en el que estoy depurando (que desgasté en este ejemplo)) varios sistemas sin éxito. Estoy un poco perdido aquí.

Editar: He probado las sugerencias de gmbeard. Desactivar las optimizaciones (-O0) no cambió nada en la pila de llamadas producida por gdb.

Ejecutar ldd en el programa me da:

linux-vdso.so.1 => (0x00007ffe3b7f1000)
libglut.so.3 => /usr/lib/x86_64-linux-gnu/libglut.so.3 (0x00007f04978fa000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f04975f6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f04973e0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f049701b000)
libGL.so.1 => /usr/lib/nvidia-352/libGL.so.1 (0x00007f0496cec000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f04969b7000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f04966b1000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f04964a1000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f049629b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0497b44000)
libnvidia-tls.so.352.21 => /usr/lib/nvidia-352/tls/libnvidia-tls.so.352.21 (0x00007f0496098000)
libnvidia-glcore.so.352.21 => /usr/lib/nvidia-352/libnvidia-glcore.so.352.21 (0x00007f0493607000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f04933f5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f04931f1000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f0492fd2000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f0492dce000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f0492bc8000)

Y luego, habiendo identificado qué libGL estoy usando, ejecuté ldd en él

linux-vdso.so.1 => (0x00007ffc55df8000)
libnvidia-tls.so.352.21 => /usr/lib/nvidia-352/tls/libnvidia-tls.so.352.21 (0x00007faa60d83000)
libnvidia-glcore.so.352.21 => /usr/lib/nvidia-352/libnvidia-glcore.so.352.21 (0x00007faa5e2f2000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007faa5dfbd000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007faa5ddab000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faa5d9e6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faa5d7e2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faa5d4dc000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007faa5d2bd000)
/lib64/ld-linux-x86-64.so.2 (0x00007faa612b5000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007faa5d0b9000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007faa5ceb3000)

Pero una mirada rápida no revela nada extraño.

Answer 1

Entonces ves en la salida LD_DEBUG:

Lo último que imprime es: "20863: symbol = __ pthread_key_create; lookup in file = / usr / lib / x86_64-linux-gnu / libXdmcp.so.6 [0]

Significa que ld.so id está buscando __pthread_key_create ya que es necesario para uno de tu biblioteca [y será mejor que encuentres qué biblioteca necesita este símbolo, posiblemente responda qué biblioteca necesita libpthread.so].

Entonces __pthread_key_create debe estar en libpthread.so pero no tiene libpthread.so en su salida ldd . Como puede ver a continuación, su programa se bloquea posiblemente al usar __pthread_key_create en init (). Por cierto, puedes probar también

LD_PRELOAD=/lib64/libpthread.so.0 ./main

para asegurarse de que pthread_key_create se carga antes que otros símbolos.

Entonces, es poco probable que sea un problema. Simplemente llama a dlsym en la inicialización y es un comportamiento absolutamente correcto. Pero el programa falla:

#0 0x0000000000000000 in ?? ()
#1 0x00007ffff3488291 in init () at dlerror.c:177
#2 0x00007ffff34886d7 in _dlerror_run (operate=operate@entry=0x7ffff3488130 <dlsym_doit>, args=args@entry=0x7fffffffddf0) at dlerror.c:129

Esta traza inversa muestra que se llamó a una función con dirección 0x00000000 (supongo que todavía no se ha resuelto la dirección de __pthread_key_create) y eso es un error. ¿Qué función se llamó? Mira las fuentes:

Esto es dlerror.c: 129 (frame # 2):

int
internal_function
_dlerror_run (void (*operate) (void *), void *args)
{
struct dl_action_result *result;
/* If we have not yet initialized the buffer do it now. */
__libc_once (once, init);

(cuadro n. ° 1):

/* Initialize buffers for results. */
static void
init (void)
{
if (__libc_key_create (&key, free_key_mem))
/* Creating the key failed. This means something really went
wrong. In any case use a static buffer which is better than
nothing. */
static_buf = &last_result;
}

Debe ser __libc_key_create que es una macro y tiene en glibc diferentes definiciones. Si compila para POSIX, se define

/* Create thread-specific key. */
#define __libc_key_create(KEY, DESTRUCTOR) /
__libc_ptf_call (__pthread_key_create, (KEY, DESTRUCTOR), 1)

Te pedí que construyeras con:

g++ -pthread -Wall -g main.cpp -lpthread -lglut -lGL -lGLU -o main

Para asegurarse de que __libc_key_create de hecho llama a __pthread_key_create y lpthread se inicializa antes de -lglut. Pero si no quieres usar -pthread, entonces posiblemente necesites analizar el frame # 1

#1 0x00007ffff3488291 in init () at dlerror.c:177

Por ejemplo, puede agregar un desarme para el cuadro n. ° 1 a su pregunta

Answer 2

Es posible que su programa y libGL estén vinculados con, o que usen, dos versiones conflictivas de una tercera biblioteca (¿tal vez libc?). Es difícil diagnosticar con los detalles que ha proporcionado. Podría desactivar las optimizaciones ( -O0 ) y ver si GDB deja de tener más pistas. Podrías ver qué dependencias tienen tu programa y libGL ejecutando ldd , esto muestra las dependencias en tiempo de compilación. Lo siento, solo puedo dar sugerencias: estos tipos de problemas de tiempo de ejecución pueden ocurrir por varias razones.

Answer 3

Encontré un problema similar, pero LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 ./main no siempre funcionaba. Este problema ocurrió en NVIDIA GPU, OpenGL está vinculado a /usr/lib/nvidia-352/libGL.so.1 , luego de probarlo en diferentes computadoras, encuentro que el cambio de la versión de g ++ a g ++ - 5 funciona, o el enlace a ''mesa / libGL .so '', otra implementación OpenGL, por g++ main.cpp -o main -Wl, --rpath /usr/lib/x86_64-linux-gnu/mesa -lGLU -lGL -lglut .