3

gdb 报告说我的 C 代码在malloc(). 现在我的代码更早地出现了段错误，但 gdb 的输出更加令人困惑：

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x30026b00 (LWP 4003)]
0x10007c30 in simulated_status (axis=1, F=0x300e7fa8, B=0x1003a520, A=0x3013b000, p=0x1003b258, XS=0x3013b000)
    at ccp_gch.c:799

编辑：完整的回溯：

(gdb) bt
#0  0x10007c30 in simulated_status (axis=1, F=0x300e7fa8, B=0x1003a520, A=0x3013b000, p=0x1003b258, XS=0x3013b000)
    at ccp_gch.c:799
#1  0x10007df8 in execute_QUERY (F=0x300e7fa8, B=0x1003a520, iData=0x7fb615c0) at ccp_gch.c:836
#2  0x10009680 in execute_DATA_cmd (P=0x300e7fa8, B=0x7fb615cc, R_type=0x7fb615d0, iData=0x7fb615c0)
    at ccp_gch.c:1581
#3  0x10015bd8 in do_volley (client=13) at session.c:76
#4  0x10015ef4 in do_dialogue (v=12, port=2007) at session.c:149
#5  0x10016350 in do_session (starting_port=2007, ports=1) at session.c:245
#6  0x100056e4 in main (argc=2, argv=0x7fb618f4) at main.c:271

相关代码（因原因稍作修改）：

796  static uint32_t simulated_status(
797      unsigned axis, struct foo *F, struct bar *B, struct Axis *A, BAZ *p, uint64_t *XS)
798  {
799      uint32_t result = A->status;
800      *XS = get_status(axis);
801      if (!some_function(p)) {
802          ...

要检查的显而易见的事情是是否A->status是有效的内存，但确实如此。删除分配会将段错误推送到第 800 行，删除该分配会导致 if 块中的一些其他分配出现段错误。看起来好像访问传递给函数的参数或写入局部变量是导致段错误的原因，但根据 gdb，一切都指向有效内存。

我该如何解释这个？我以前从未见过这样的事情，所以任何正确方向的建议/指针都将不胜感激。我正在使用 GNU gdb 6.8-debian、Electric Fence 2.1，并在 PowerPC 405 上运行（uname 报告Linux powerpmac 2.6.30.3 #24 [...] ppc GNU/Linux）。

4

1 回答 1

0

我猜，但你的症状类似于堆栈溢出情况下可能发生的情况。评论中的-fstack-protector建议在这里是正确的。我建议也添加-fstack-check选项。

如果SEGV由于写入保护堆栈的保护页面而发生这种情况，那么 gdb 中的info registersandinfo frame将有助于确认是否是这种情况。

于 2014-03-30T12:18:42.133 回答