Question

我正在尝试在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仓库下载的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使用SIGSTOP停止了许多内核调用（睡眠，semwait等），我可以按Continue，但这使调试变得不切实际。

如果将以下行添加到.gdbinit handle SIGSTOP nostop noprint pass中，则gdb不会在内核调用时停止，但是现在断点不起作用，并且很难停止gdb或正在调试的进程。

Answer 1

GDB服务器应用程序是为此工作而制作的。安装在R / T系统上，登录到R / T系统并运行GDB服务器应用程序。在本地（在您的计算机上）运行GDB，连接到GDB服务器应用程序。等等。我已经做了很多次，但是已经有好几年了。建议谷歌搜索详细信息

如何remote gdb

如何在RT Linux上使用GDB进行调试：SIGTRAP

1 个答案: