在SEGFAULT的情况下，了解GDB输出

Question

我的程序中有一个segfault。我尝试使用gdb的backtrace命令来查找错误，但不幸的是，我不了解其输出：

(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

有人知道Segfault的来源吗？例如，为什么main方法未在backtrace的输出中列出？

Answer 1

有人知道segfault来自何处吗？

是：gdb tell 您来自哪里： libnvidia-opencl.so.1

内的地址 0x7ffff1678480的未命名功能

例如，为什么未在回溯输出中列出的主要方法？

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

那么，你该怎么办？

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

you 应该 遍历您程序所做的任何OpenCL调用（假设它可以做到），并验证您提供的参数是否有效并满足OpenCL API要求。

您还应该做(gdb) thread apply all where以查看其他线程在哪里。也许您的主线程未正确关闭OpenCl。

您还可以尝试使用不同的（可能较低的性能）开源OpenCL实现（例如POCL）运行程序。如果碰撞以pocl复制，您将有更轻松的时间了解出了什么问题，因为您可以检查源出现问题。

Answer 2

从底部开始并开始工作：

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

我看到一个称为 clone的函数。我本地键入man clone并获得这样的东西。

第四段是

clone（）的一种用途是实现线程： 在共享内存空间中同时运行的程序中的控制。

当我查看下一个堆栈帧

时，这似乎很重要

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

我在模块pthread_create中看到一个称为start_thread的函数。嗯，线程，线程，我以前在某个地方看到了这个词。我记得以前在某个地方看到pthread_create，所以键入man pthread_create ...

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

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