#1 楼
如果您的断点地址位于操作码的“中间”，则可能发生这种情况，例如，如果您的asm代码如下所示： 0x00D，在这种情况下，该进程将在除0x000D之外的其他地址上获取SIGTRAP，但gdb仅从用户输入中知道0x00D地址，因此它只会抛出SIGTRAP并卡住。如果将地址正确分配给gdb，则gdb的arm后备模式可能会导致此类问题。0x000C: BLX R3
0x000E: LDR R0, [R6]
有时gdb无法自动获得功能的Arm模式，并且它跌入了错误的模式。您可以通过在gdb中反汇编一段代码来检查这一点，并检查是否看到正常的汇编或某些不良的汇编。如果它不好，那么您的手臂装配模式是错误的，并且您会得到错误的SIGTRAP。
另一建议是不要在iOS中使用gdb，请使用lldb。 gdb已贬值，iOS可用的唯一gdb版本是个人书写的端口，这些端口缺少功能（例如，其中一些根本不具有后备功能），并且不可靠。
#2 楼
如果程序由于某种奇怪的原因合法地触发了SIGTRAP本身，并且依赖于这种情况，那么您可以通过执行以下命令来告诉gdb返回程序并执行程序自己的SIGTRAP处理：signal SIGTRAP 就像
c继续一样，只不过它在SIGTRAP处理程序而不是在引发异常/陷阱的地方继续。#3 楼
即使程序中没有断点，如果仍然遇到此错误Received a SIGTRAP: Trace/breakpoint trap，请检查硬件调试器的电源，例如J-Link。 就我而言，J-Link已打开电源，但端口没有提供足够的电源。将端口更改为大功率端口即可解决此问题。