c++ - gdb 错误 : Backtrace stopped: previous frame identical to this frame (corrupt stack? )

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 上重现错误。

软件问题

似乎有两个线程被卡住了，可能是由于两个互斥量的死锁，或者一个线程试图第二次获得一个互斥量(尽管这似乎不太可能，但在我将互斥量配置为递归 之后，错误出现了；我将不得不检查该线程中使用的第二个互斥量)。

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

软件构建和调试配置

build设置:

我正在使用 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 构建找到错误(互斥锁死锁)。

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

Answer 1

I've then downloaded the debug libraries which are available for the target/distribution and replaced the original shared libs with those.

这可能是错误的做法(取决于您所说的“调试库”的确切含义)，并且可能会导致您的问题。参见 this answer .

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