0

我有一个对我没有任何意义的分段错误。第 538 次调用这个函数,它失败了,但我看不出参数有什么问题。我可以在 gdb 中输入相同的表达式,它会很乐意这样做而不会抱怨。我什至使用 si 爬到它上面并查看了寄存器,但它仍然没有任何意义。我该如何解决这个问题?

一件奇怪的事情是 gdb 报告“位”参数在故障处已从 0 变为 1。我想“位”在一个被重用于其他东西的寄存器中。

我也试过这个没有优化。涉及的指令更多,但结果是一样的。

请注意,下面我使用 gdb 访问代码即将访问的相同位置,没有问题。

代码:

void Bits::set(int bit)
{
    if (bit >= _size*16) BUG;
    _dat[bit/16] |= 1 << (bit & 15);
}

gdb 运行:

Breakpoint 1, Bits::set (this=0x68374, bit=0) at util.cpp:181
181         _dat[bit/16] |= 1 << (bit & 15);
1: x/i $pc
=> 0x3964c <_ZN4Bits3setEi+36>: ldr     r3, [r0, #4]
(gdb) si
0x00039650      181         _dat[bit/16] |= 1 << (bit & 15);
1: x/i $pc
=> 0x39650 <_ZN4Bits3setEi+40>: mov     r1, #1
(gdb)
0x00039654      181         _dat[bit/16] |= 1 << (bit & 15);
1: x/i $pc
=> 0x39654 <_ZN4Bits3setEi+44>: ldrh    r2, [r12, r3]
(gdb)
0x00039658      181         _dat[bit/16] |= 1 << (bit & 15);
1: x/i $pc
=> 0x39658 <_ZN4Bits3setEi+48>: orr     r2, r2, r1, lsl lr
(gdb)
0x0003965c      181         _dat[bit/16] |= 1 << (bit & 15);
1: x/i $pc
=> 0x3965c <_ZN4Bits3setEi+52>: strh    r2, [r12, r3]
(gdb) p _dat
$18 = (short *) 0x4ee74
(gdb) p *_dat
$19 = -3784
(gdb) p $r2
$20 = 61753
(gdb) p $r12
$21 = 0
(gdb) p/x $r3
$22 = 0x4ee74
(gdb) si

Program received signal SIGSEGV, Segmentation fault.
0x0003965c in Bits::set (this=0x68374, bit=1) at util.cpp:181
181         _dat[bit/16] |= 1 << (bit & 15);
1: x/i $pc
=> 0x3965c <_ZN4Bits3setEi+52>: strh    r2, [r12, r3]
(gdb)

顺便说一句,我在这里使用 gdbserver。这是目标响应:

50:/mnt/home/rw # ./gdbserver x:12 cx Andersen_Studio.cxc
Process cx created; pid = 226
Listening on port 12
Remote debugging from host 192.168.1.40

pc : [<0003965c>]    lr : [<00000000>]    Tainted: P
sp : 7ffffdb4  ip : 00000000  fp : 7ffffe84
r10: 2ada7884  r9 : 0000c6c8  r8 : 2ada8d28
r7 : 00000002  r6 : 0005c0b8  r5 : 00000000  r4 : 0006dc10
r3 : 0004ee74  r2 : 0000f139  r1 : 00000001  r0 : 00068374
Flags: Nzcv  IRQs on  FIQs on  Mode USER_32  Segment user
Control: C000317F  Table: 017EC000  DAC: 00000015

更多信息:如果我手动执行命令,则不会发生故障:

Breakpoint 1, Bits::set (this=0x6c75c, bit=0) at util.cpp:181
181         _dat[bit/16] |= 1 << (bit & 15);
(gdb) c 538
Will ignore next 537 crossings of breakpoint 1.  Continuing.

Breakpoint 1, Bits::set (this=0x68374, bit=0) at util.cpp:181
181         _dat[bit/16] |= 1 << (bit & 15);
(gdb) p _dat[bit/16] |= 1 << (bit & 15)
$25 = -3783
(gdb) dis 1
(gdb) c
Continuing.

仅引用 _dat[0] 并没有帮助,但例如键入 _dat[0]=0 确实可以防止出现问题。

(稍后编辑)

如果我们要查看为函数生成的代码,我决定关闭优化。这是未优化的代码:

(gdb) disass
Dump of assembler code for function _ZN4Bits3setEi:
   0x0006a1d8 <+0>:     mov     r12, sp
   0x0006a1dc <+4>:     push    {r11, r12, lr, pc}
   0x0006a1e0 <+8>:     sub     r11, r12, #4
   0x0006a1e4 <+12>:    sub     sp, sp, #8
   0x0006a1e8 <+16>:    str     r0, [r11, #-16]
   0x0006a1ec <+20>:    str     r1, [r11, #-20]
=> 0x0006a1f0 <+24>:    ldr     r3, [r11, #-16]
   0x0006a1f4 <+28>:    ldr     r3, [r3]
   0x0006a1f8 <+32>:    lsl     r2, r3, #4
   0x0006a1fc <+36>:    ldr     r3, [r11, #-20]
   0x0006a200 <+40>:    cmp     r3, r2
   0x0006a204 <+44>:    blt     0x6a220 <_ZN4Bits3setEi+72>
   0x0006a208 <+48>:    ldr     r0, [pc, #108]  ; 0x6a27c <_ZN4Bits3setEi+164>
   0x0006a20c <+52>:    ldr     r1, [pc, #108]  ; 0x6a280 <_ZN4Bits3setEi+168>
   0x0006a210 <+56>:    mov     r2, #180        ; 0xb4
   0x0006a214 <+60>:    bl      0xa00c <printf>
   0x0006a218 <+64>:    mov     r0, #1
   0x0006a21c <+68>:    bl      0xa09c <exit>
   0x0006a220 <+72>:    ldr     r1, [r11, #-16]
   0x0006a224 <+76>:    ldr     r2, [r11, #-20]
   0x0006a228 <+80>:    asr     r3, r2, #31
   0x0006a22c <+84>:    lsr     r3, r3, #28
   0x0006a230 <+88>:    add     r3, r2, r3
   0x0006a234 <+92>:    asr     r0, r3, #4
   0x0006a238 <+96>:    mov     r3, r0
   0x0006a23c <+100>:   lsl     r2, r3, #1
   0x0006a240 <+104>:   ldr     r3, [r1, #4]
   0x0006a244 <+108>:   add     r12, r2, r3
   0x0006a248 <+112>:   ldr     r1, [r11, #-16]
   0x0006a24c <+116>:   mov     r3, r0
   0x0006a250 <+120>:   lsl     r2, r3, #1
   0x0006a254 <+124>:   ldr     r3, [r1, #4]
   0x0006a258 <+128>:   add     r1, r2, r3
   0x0006a25c <+132>:   ldr     r3, [r11, #-20]
   0x0006a260 <+136>:   and     r2, r3, #15
   0x0006a264 <+140>:   mov     r3, #1
   0x0006a268 <+144>:   lsl     r3, r3, r2
   0x0006a26c <+148>:   ldrh    r2, [r1]
   0x0006a270 <+152>:   orr     r3, r2, r3
   0x0006a274 <+156>:   strh    r3, [r12]
   0x0006a278 <+160>:   ldmdb   r11, {r11, sp, pc}
   0x0006a27c <+164>:   andeq   r8, r8, r0, lsr r12
   0x0006a280 <+168>:   andeq   r8, r8, r4, asr r12
End of assembler dump.
(gdb)

我尝试插入 _dat[0] = 0; 在“坏”声明之前,这会导致错误。我试过 _dat[0]++; 这也有问题。

4

3 回答 3

3

嗯,看起来一切正常。您可以从该位置读取,但不能写入...奇怪。

我脑海中浮现以下想法:

  • 永远不要相信 gdb 显示给你的东西。当您在 gdb 中评估一个表达式时,这与您的代码所做的完全不同。特别是它不会使用您的代码(除非您明确地按名称调用函数)。Gdb 将使用调试信息,这些信息通常有差距并且有很大的解释空间,而您的代码将只使用您的代码。:-) gdb 中的变量值通常是错误的。这很可能甚至不是 gdbs 的错误。gdb 不能比编译器生成的调试信息更好。它甚至包含大量(与调试信息相关的)编译器错误的启发式方法。

  • 您的操作系统可能会将许多不同的故障情况映射到 Segfault。例如,这可能是异步数据中止,在这种情况下,真正的问题可能早于数百条指令。

  • 您是否使用安全和非安全内存?通过高速缓存从非安全模式写入安全内存可能会导致异步数据中止。

  • 这个函数运行了 537 次 OK 的事实并不意味着什么。它是否在完全相同的数据/内存位置上运行?我的意思是,该set()函数本质上只是一个内存写入。行为(是否崩溃)将始终取决于变量的内容 bit

当我在我的程序中看到对我没有任何意义的奇怪崩溃时,我会修改该函数,使其行为略有不同。如果你这样做会发生什么:

void Bits::set(int bit)
{
    if (bit >= _size*16) BUG;
    _dat[bit/16] = 42; // does this crash?
    _dat[0] = 42;      // does this crash?
    _dat[bit/16]++;    // does this crash?
    _dat[bit/16] |= 1 << (bit & 15);
}

(如果您的程序依赖于此,您可能需要保存/恢复写入的位置。)

还有助于将程序中的诊断消息打印到一些日志中。这通常比使用调试器更好,因为它使用您的代码和实际值,而不是使用调试信息。

于 2013-04-06T21:31:40.780 回答
1

我不知道为什么在这个特定的行会出现分段错误,因为使用 gdb 修改内存似乎没有问题。但是,通过在 Bits 构造函数中打印出“this”,并将其与错误处的“this”进行比较,我发现我必须遭受内存损坏,可能在远离这里的某个地方。因此,我将中断这一调查并继续假设问题出在其他地方。

(之后)

我发现了问题,它是一个未初始化的指向 Bits 的指针(令人惊讶!),它恰好足够可信,以至于表面上看起来好像它是正确的。为我指明正确方向的想法是“记录事物”的想法,我刚刚用 printf 做到了这一点。

于 2013-04-06T23:07:01.157 回答
-1

1) 所以你说执行 ARM 汇编指令 strh r2, [r12, r3] 会导致访问冲突。

2) 问:0x4ee74(包含在 r3 中)是否有效?

3) 问:0000f139(包含在 r2 中)是否有效?从手册:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/BABDJCHA.html

字和半字传输的地址对齐:

地址必须是 4 的倍数。

如果您的系统有系统协处理器 (cp15),您可以启用对齐检查。如果启用对齐检查,非对齐传输会导致对齐异常。

如果您的系统没有系统协处理器 (cp15),或者对齐检查被禁用:

未对齐的负载会破坏 Rd。

非对齐保存会破坏内存中的四个字节。内存中损坏的位置是 [address AND NOT b11]。

于 2013-04-06T18:00:00.933 回答