程序接收信号SIGTRAP，跟踪/断点陷阱。
我知道之前已经问过这个问题，但是我已经阅读了所有的主题并且没有找到答案。 从我执行run开始调试我的项目的那一刻起，我得到了： Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 6] Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 6] 。 当我执行ctrl+c ，gdb告诉我： Program received signal SIGINT, Interrupt. 0x00000000 in ?? () Program received signal SIGINT, Interrupt. 0x00000000 in ?? ()
通常它会告诉我哪个文件和哪个函数在不是0x00000000 in ?? ()时被中断0x00000000 in ?? () 0x00000000 in ?? () GDB不再遇到断点，让事情变得更加疯狂的事实是，我和同事正在共享相同的会话（调试是使用cygwin和远程机器完成的），它对他们来说很好但不适合我。 当我尝试使用info threads获取有关线程的info threads ，我得到的是：
[New Thread 20] [New Thread 21] [New Thread 22] Id Target Id Frame 4 Thread 22 (ssp=0xa9004d5c) 0x00000000 in ?? () 3 Thread 21 (ssp=0xa9002e64) 0x00000010 in ?? () 2 Thread 20 (ssp=0xa9000ef4) 0x00000000 in ?? () The current thread has terminated. See `help thread'
没有线程6，没有*表示gdb正在使用哪个线程。 我甚至不知道这是否与问题有关。 谁能帮帮我吗？
实际上，这与您的其他问题重复。
正如我在那里的评论中所说，你没有提供足够的信息来帮助你。 细节很重要 ，你扣留它们。 GDB和gdbserver的版本很重要，你如何调用GDB和gdbserver，从GDB（如果有的话）收到什么警告。
现在，此错误消息：
Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 6]
通常意味着gdbserver没有连接进程的一个线程，并且该线程已经尝试执行断点指令（在这种情况发生之前你确实设置了断点，不是吗？）。
可能发生这种情况的原因之一是当您的GDB加载“错误的” libthread_db.so （与目标libc.so.6不匹配时）。
让事情变得更加疯狂的事实是，我和一位同事正在共享同一个会话（调试是使用cygwin和远程机器完成的），它对他们来说很好但不适合我。
我不确定你的意思是“同一个会话”，但它可能不是“当他输入命令时，它们可以工作;但是当我在相同的GDB中键入相同的命令时，它们不会”。
您和您的同事之间的一个区别可能是LD_LIBRATY_PATH环境变量设置。 另一个可以在~/.gdbinit或./.gdbinit 。
我建议运行gdb -nx来摆脱后者，并取消设置LD_LIBRARY_PATH以摆脱前者。
整个事情的问题，由于某种原因没有人似乎注意到这是：这就是我如何调用gdb /usr/local/build/gdbx.y/gdb/gdb我应该做的是： /usr/local/build/gdbx.y/build/gdb/gdb这是一个路径问题。