使用 glut 和 std::string 时 main() 之前的分段错误?
Segmentation Fault before main() when using glut, and std::string?
在 64 位 Ubuntu 14.04 LTS 上,我正在尝试编译一个使用 glut 的简单 OpenGL 程序。在 main 中执行任何代码行之前,我遇到了分段错误 (SIGSEV);即使是在一个非常精简的测试程序上。这可能是什么原因造成的?
我的命令行:
g++ -Wall -g main.cpp -lglut -lGL -lGLU -o main
我的简单测试用例:
#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;
}
当我运行程序时,main开头的printf在段错误之前没有执行。
在 GDB 下,我在段错误
之后得到了这个回溯
#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 ?? ()
这是关键。如果我注释掉 gluInit 行或 std::string 虚拟行,程序编译并且 运行 就好了。直到我注意到这一点之前,我一直认为我的 GLUT 有问题(尽管我已经尝试了我正在调试的原始程序(我精简到这个例子))几个系统都没有成功。我在这里有点不知所措。
编辑:我已经尝试了 gmbeard 的建议。关闭优化 (-O0) 不会改变 gdb 生成的调用堆栈的任何内容。
运行 ldd 在程序上给我:
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)
然后,在确定我使用的是哪个 libGL 之后,我 运行 ldd 就可以了
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)
但快速浏览一下并没有发现任何问题。
您的程序和 libGL 可能链接或使用了第三个库(可能是 libc?)的两个冲突版本。很难根据您提供的详细信息进行诊断。您可以禁用优化 (-O0
) 并查看 GDB 是否提供任何进一步的线索。您可以通过 运行 ldd
查看您的程序和 libGL 都有哪些依赖项 - 这显示了编译时依赖项。抱歉,我只能提供建议 - 这些类型的运行时问题可能由于多种原因而发生。
所以你在 LD_DEBUG 输出中看到:
The last thing it prints out is: " 20863: symbol=__pthread_key_create;
lookup in file=/usr/lib/x86_64-linux-gnu/libXdmcp.so.6 [0]
这意味着 ld.so id 正在寻找 __pthread_key_create
因为你的图书馆之一需要它 [而且你最好找到这个符号需要什么图书馆,它可能会回答什么图书馆需要 libpthread.so].
因此 __pthread_key_create
必须在 libpthread.so 中,但您的 ldd
输出中没有 libpthread.so
。正如您在下面看到的,您的程序可能在 init() 中使用 __pthread_key_create 时崩溃。顺便说一句,你也可以试试
LD_PRELOAD=/lib64/libpthread.so.0 ./main
为了确保 pthread_key_create
在其他符号之前加载。
所以lgut
不太可能成为问题。它只是在初始化时调用 dlsym,这是绝对正确的行为。但是程序崩溃了:
#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
此回溯显示调用了地址为 0x00000000 的函数(我猜它是 __pthread_key_create 的未解析地址),这是一个错误。调用了什么函数?查看来源:
这是 dlerror.c:129(第 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);
(第 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;
}
它必须是 __libc_key_create
是一个宏,它在 glibc 中有不同的定义。如果你为 POSIX 构建,它被定义为
/* Create thread-specific key. */
#define __libc_key_create(KEY, DESTRUCTOR) \
__libc_ptf_call (__pthread_key_create, (KEY, DESTRUCTOR), 1)
我要求你构建:
g++ -pthread -Wall -g main.cpp -lpthread -lglut -lGL -lGLU -o main
为了确保 __libc_key_create
实际上调用 __pthread_key_create
并且 lpthread 在 -lglut 之前被初始化。但是如果你不想使用 -pthread 那么你可能需要分析帧 #1
#1 0x00007ffff3488291 in init () at dlerror.c:177
例如,您可以将第 1 帧的反汇编添加到您的问题中
我遇到了类似的问题,但 LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 ./main
并非总是有效。这个问题发生在 NVIDIA GPU 上,OpenGL 链接到 /usr/lib/nvidia-352/libGL.so.1
,在不同的计算机上测试后,我发现将 g++ 版本更改为 g++-5 可以工作,或者链接到 'mesa/libGL.so',另一个 OpenGL 实现,通过 g++ main.cpp -o main -Wl, --rpath /usr/lib/x86_64-linux-gnu/mesa -lGLU -lGL -lglut
.
在 64 位 Ubuntu 14.04 LTS 上,我正在尝试编译一个使用 glut 的简单 OpenGL 程序。在 main 中执行任何代码行之前,我遇到了分段错误 (SIGSEV);即使是在一个非常精简的测试程序上。这可能是什么原因造成的?
我的命令行:
g++ -Wall -g main.cpp -lglut -lGL -lGLU -o main
我的简单测试用例:
#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;
}
当我运行程序时,main开头的printf在段错误之前没有执行。 在 GDB 下,我在段错误
之后得到了这个回溯#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 ?? ()
这是关键。如果我注释掉 gluInit 行或 std::string 虚拟行,程序编译并且 运行 就好了。直到我注意到这一点之前,我一直认为我的 GLUT 有问题(尽管我已经尝试了我正在调试的原始程序(我精简到这个例子))几个系统都没有成功。我在这里有点不知所措。
编辑:我已经尝试了 gmbeard 的建议。关闭优化 (-O0) 不会改变 gdb 生成的调用堆栈的任何内容。
运行 ldd 在程序上给我:
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)
然后,在确定我使用的是哪个 libGL 之后,我 运行 ldd 就可以了
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)
但快速浏览一下并没有发现任何问题。
您的程序和 libGL 可能链接或使用了第三个库(可能是 libc?)的两个冲突版本。很难根据您提供的详细信息进行诊断。您可以禁用优化 (-O0
) 并查看 GDB 是否提供任何进一步的线索。您可以通过 运行 ldd
查看您的程序和 libGL 都有哪些依赖项 - 这显示了编译时依赖项。抱歉,我只能提供建议 - 这些类型的运行时问题可能由于多种原因而发生。
所以你在 LD_DEBUG 输出中看到:
The last thing it prints out is: " 20863: symbol=__pthread_key_create; lookup in file=/usr/lib/x86_64-linux-gnu/libXdmcp.so.6 [0]
这意味着 ld.so id 正在寻找 __pthread_key_create
因为你的图书馆之一需要它 [而且你最好找到这个符号需要什么图书馆,它可能会回答什么图书馆需要 libpthread.so].
因此 __pthread_key_create
必须在 libpthread.so 中,但您的 ldd
输出中没有 libpthread.so
。正如您在下面看到的,您的程序可能在 init() 中使用 __pthread_key_create 时崩溃。顺便说一句,你也可以试试
LD_PRELOAD=/lib64/libpthread.so.0 ./main
为了确保 pthread_key_create
在其他符号之前加载。
所以lgut
不太可能成为问题。它只是在初始化时调用 dlsym,这是绝对正确的行为。但是程序崩溃了:
#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
此回溯显示调用了地址为 0x00000000 的函数(我猜它是 __pthread_key_create 的未解析地址),这是一个错误。调用了什么函数?查看来源:
这是 dlerror.c:129(第 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);
(第 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;
}
它必须是 __libc_key_create
是一个宏,它在 glibc 中有不同的定义。如果你为 POSIX 构建,它被定义为
/* Create thread-specific key. */
#define __libc_key_create(KEY, DESTRUCTOR) \
__libc_ptf_call (__pthread_key_create, (KEY, DESTRUCTOR), 1)
我要求你构建:
g++ -pthread -Wall -g main.cpp -lpthread -lglut -lGL -lGLU -o main
为了确保 __libc_key_create
实际上调用 __pthread_key_create
并且 lpthread 在 -lglut 之前被初始化。但是如果你不想使用 -pthread 那么你可能需要分析帧 #1
#1 0x00007ffff3488291 in init () at dlerror.c:177
例如,您可以将第 1 帧的反汇编添加到您的问题中
我遇到了类似的问题,但 LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 ./main
并非总是有效。这个问题发生在 NVIDIA GPU 上,OpenGL 链接到 /usr/lib/nvidia-352/libGL.so.1
,在不同的计算机上测试后,我发现将 g++ 版本更改为 g++-5 可以工作,或者链接到 'mesa/libGL.so',另一个 OpenGL 实现,通过 g++ main.cpp -o main -Wl, --rpath /usr/lib/x86_64-linux-gnu/mesa -lGLU -lGL -lglut
.