Question

我的程序中有段错误。我尝试使用backtrace的{{1}}命令来查找错误，但不幸的是，我不明白它的输出：

gdb

有谁知道segfault的来源？例如，为什么(gdb) bt #0 0x00007ffff1678480 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 #1 0x00007ffff171c11e in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 #2 0x00007ffff17e565f in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 #3 0x00007ffff17432e3 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 #4 0x00007ffff16580bf in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 #5 0x00007ffff179e758 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 #6 0x00007ffff173cea8 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1 #7 0x00007ffff6b8770a in start_thread (arg=0x7fffef352700) at pthread_create.c:333 #8 0x00007ffff68bd82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109方法未在main的输出中列出？

Answer 1

有谁知道segfault的来源？

是的：GDB 告诉您来自哪里：0x7ffff1678480内libnvidia-opencl.so.1地址的未命名函数

例如，为什么主要方法没有列在backtrace的输出中？

因为崩溃发生在主线程以外的线程中。

那么，你应该怎么做？

由于您使用的是供应商提供且完全不透明的库，因此您几乎没有可以做什么来理解此崩溃。

你应该检查你的程序执行的任何OpenCL调用（假设它做了任何调用），并验证你提供的参数是否有效并满足OpenCL API要求。

您还应该(gdb) thread apply all where查看其他线程的位置。也许你的主线程正在退出而没有正确关闭OpenCL。

您还可以尝试使用不同（可能性能较低）的开源OpenCL实现（例如pocl）运行您的程序。 IF 崩溃再现pocl，您可以更轻松地了解出现了什么问题，因为您可以检查来源，GDB会告诉您完全哪里在源头发生了问题。

Answer 2

从底部开始并进行处理：

#8  0x00007ffff68bd82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

我看到一个名为clone的函数。我在本地输入man clone并获得类似this的内容。

第四段是

clone（）的一个用途是实现线程：多个线程控制在共享内存空间中并发运行的程序。

当我查看下一个堆栈框架

时似乎相关

0x00007ffff6b8770a in start_thread (arg=0x7fffef352700) at pthread_create.c:333

我在模块start_thread中看到一个名为pthread_create的函数。嗯，线程，线程，我以前在某个地方见过这个词。我记得曾经在某处看过pthread_create，所以输入man pthread_create ...

嗯，这解释了为什么main不在堆栈跟踪中 - 这是子线程的堆栈。不是main运行的主线程。

请注意，您可以键入info threads以查看故障发生时正在运行的其他线程，以及thread 1（或任何数字）切换到另一个线程并检查其< / em> stack。

在segfault的情况下理解gdb输出

2 个答案: