【发布时间】：2026-01-22 23:30:01
【问题描述】：
我正在尝试在 RT Linux 上调试多线程应用程序。在常规 Linux 上，应用程序运行良好，GDB 也运行良好。在 RT Linux 上，应用程序运行良好，但在 GDB 下，应用程序运行几秒钟然后终止并打印：
Program terminated with signal SIGTRAP, Trace/breakpoint trap. The program no longer exists.
我无法进行回溯，也无法确定导致问题的原因。我怀疑它可能是 gdb 使用的一些库，或者可能是应用程序中的内存损坏。
我创建了 60 多个线程，还有更多是由各种看门狗和计时器创建的。 到目前为止我尝试过的：
-
检查 libpthread.so.0 和 libthread_db.so.1 之间的不匹配。我用过
objdump -s --section .comment /usr/lib64/libthread_db-1.0.so
在这两个库上，它们都提供了相同版本的 gcc，这与我用来构建应用程序的 gcc 相同
gcc --version gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
-
尝试在 gdb 中为 SIGTRAP 设置一个捕获点
catch signal SIGTRAP commands p $_siginfo.si_code end
这根本没有改变 gdb 的行为。 有任何想法吗？我应该下载新的内核库或源代码吗？
版本： 我最初的 linux 是从 CERN repo 下载的 Scientific Linux 7（基于 CentOS 7）。我还从那里下载并安装了预构建的 RT 内核。
# gdb --version
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7
# uname -r
3.10.0-957.10.1.rt56.921.el7.x86_64
gcc --version gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
一些进展 几次 gdb 本身崩溃并留下了 gdb 核心转储。使用核心文件回溯到 gdb，我发现了相同的调用堆栈——最后几个函数如下所示：
(gdb) bt
#0 0x00007fc62ca9e207 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007fc62ca9f8f8 in __GI_abort () at abort.c:90
#2 0x000000000069f5e6 in dump_core ()
#3 0x00000000006a1de5 in internal_vproblem ()
#4 0x00000000006a1e59 in internal_verror ()
#5 0x00000000006a1eff in internal_error ()
#6 0x00000000004d5149 in check_ptrace_stopped_lwp_gone ()
#7 0x00000000004d51e2 in linux_resume_one_lwp ()
#8 0x00000000004d6e44 in linux_handle_extended_wait ()
#9 0x00000000004d9cf9 in linux_nat_wait ()
#10 0x00000000004e1273 in thread_db_wait ()
#11 0x0000000000607602 in target_wait ()
#12 0x00000000005cf815 in wait_for_inferior ()
这似乎表明 gdb 存在问题，因此我使用最新源 (8.2.1) 重建了 gdb，这阻止了 gdb 崩溃。现在 GDB 在许多内核调用（睡眠、semwait 等）处停止，并带有 SIGSTOP，我可以按继续，但这使得调试不切实际。
如果我在 .gdbinit handle SIGSTOP nostop noprint pass 中添加以下行，则 gdb 不会在内核调用处停止，但现在断点不起作用，并且很难停止 gdb 或正在调试的进程。
【问题讨论】：
标签： linux multithreading gdb real-time