gdb 错误：回溯停止：前一帧与此帧相同（堆栈损坏？）

Question

我在 ARMv7 目标上调试多线程 C++ 应用程序时遇到问题。该问题出现在两个不同的 ARM 目标上，我为它们使用了不同的工具链：

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

我检查了一些线程，但是（由于与简约的多线程程序存在相同的问题）似乎我 * 没有损坏的堆栈 * 虚拟函数或函数指针的任何问题

我主要使用目标Toradex Colibri iMX6，它运行着Angstrom Linux 2016.12。

问题

• 我构建程序的方式有问题吗？
• 有什么东西吗？我使用gdbserver/ 的方式有问题gdb吗？
• 我必须使用哪些选项来修复调试器输出？

我gdbserver在目标上调试通过，工具链arm-linux-gnueabihf-gdb在我的主机上。gdb任何目标都没有本机。我可以为Linux x86构建应用程序，但目前无法在 PC 上重现该错误。

软件问题

似乎有两个线程卡住了，可能是由于两个互斥锁的死锁，或者一个线程试图第二次获取一个互斥锁（虽然这似乎不太可能，但在我将互斥锁配置为递归后出现了错误; 我将不得不检查该线程中使用的第二个互斥锁）。

所有其他线程似乎都运行良好。

软件构建和调试配置

构建设置：

我正在使用 Toradex 提供的工具链arm-linux-gnueabihf-g++和

-std=c++11 -Wall -Werror -Wextra -Wno-unused-result -Winit-self -Wmissing-include-dirs -Wpointer-arith -Wno-format-security -Wno-implicit-fallthrough -Wl,-Map=output.map -ggdb -g3 -fno-inline -O0

我将相同的程序传递给调试器（即gdbserver在目标和arm-linux-gnueabihf-gdb主机上）

$ (gdb) set sysroot </path/to/libs>
$ (gdb) file <binary>
$ (gdb) target remote IP:port

共享库：

对于共享库，我已将/usr/lib和/lib从目标复制到主机。然后我下载了可用于目标/发行版的调试库，并用这些库替换了原始共享库。

(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
0x76fcf800  0x76feaa70  Yes         /path/to/libs/lib/ld-linux-armhf.so.3
0x76fb9700  0x76fbcd2c  Yes         /path/to/libs/lib/librt.so.1
0x76f940c0  0x76fa2e0c  Yes         /path/to/libs/lib/libpthread.so.0
0x76f01630  0x76f72a10  Yes (*)     /path/to/libs/usr/lib/libstdc++.so.6
0x76e14d38  0x76e48028  Yes         /path/to/libs/lib/libm.so.6
0x76e041b0  0x76e0e7ec  Yes         /path/to/libs/lib/libgcc_s.so.1
0x76cd1000  0x76dc2b10  Yes         /path/to/libs/lib/libc.so.6
0x7449c96c  0x744a29e4  Yes         /path/to/libs/lib/libnss_files.so.2
(*): Shared library is missing debugging information.

我找不到libstdc++.so.6.

调试结果

调试在目标上崩溃的简单单线程应用程序：

• 有效，即不报告上面的错误信息

在目标上调试简单的多线程应用程序，有无死锁：

(gdb) bt
#0  0x76d6cd44 in uname () at ../sysdeps/unix/syscall-template.S:84
#1  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

在 Linux-x86 上调试同一个简单的多线程应用程序，有无死锁：

• 作品

在 PC 上调试有问题的应用程序：

• 似乎有效，但到目前为止我们无法重现该错误

在目标上调试受影响的应用程序：

Thread 1 received signal SIGINT, Interrupt.
0x76f9facc in __lll_robust_lock_wait (futex=0x257b94 <namespace1::function()::su_place+20>, private=0)
at /usr/src/debug/glibc/2.24-r0/git/nptl/lowlevelrobustlock.c:46
46    /usr/src/debug/glibc/2.24-r0/git/nptl/lowlevelrobustlock.c: No such file or directory.
(gdb) thread apply all bt

Thread 6 (Thread 6606.6630):
#0  0x76d832c8 in __setreuid (ruid=8, euid=0)
at /usr/src/debug/glibc/2.24-r0/git/sysdeps/unix/sysv/linux/i386/setreuid.c:29
#1  0x7efff06c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 5 (Thread 6606.6629):
#0  0x76d55d44 in uname () at ../sysdeps/unix/syscall-template.S:84
#1  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 6606.6628):
#0  0x76d55d44 in uname () at ../sysdeps/unix/syscall-template.S:84
#1  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 6606.6627):
#0  0x76d55d44 in uname () at ../sysdeps/unix/syscall-template.S:84
#1  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (Thread 6606.6626):
#0  __lll_robust_lock_wait (
futex=0x25b950 <namespace_2::a_function()::a_static_member+152>, private=128)
at /usr/src/debug/glibc/2.24-r0/git/nptl/lowlevelrobustlock.c:31
#1  0x00000080 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 6606.6606):
#0  0x76f9facc in __lll_robust_lock_wait (futex=0x257b94 <namespace1::function()::su_place+20>, 
private=0) at /usr/src/debug/glibc/2.24-r0/git/nptl/lowlevelrobustlock.c:46
#1  0x00000002 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

更新

我可以找到valgrind与软件的 PC-build 一起使用的错误（互斥锁死锁）。

但是，这里的问题是关于 的问题gdb，我还无法理解或解决。

Answer 1

然后，我下载了可用于目标/发行版的调试库，并用这些库替换了原始的共享库。

这可能是错误的做法（取决于“调试库”的确切含义），并且可能会导致您的问题。看到这个答案。

第一步，我将使用与您在目标上使用的完全相同的库，并检查这是否会改变 GDB 的行为。