为什么我会遇到seg故障？

得到seg故障后，我使用了gdb a.out core命令。后来我用backtrace（bt），这是gdb告诉我的为什么我会遇到seg故障？

警告：核心文件可能与指定的可执行文件不匹配。

警告：错误读数在0xfbe8

警告共享库列表条目：错误读取共享库列表条目在0x74c085ff

核心是通过“family.out smith.ged”产生。

程序以信号11终止，分段故障。

（poundsign）0 0x08086a6在count_records（）

（GDB）BT

（poundsign）0 0x080486a6在count_records（）

（poundsign）1 0x08048906在__libc_csu_init（）

（英镑）2 0xbf85624c在??（）

（英镑）3 0xbf856310在?? （）

回溯停止：以前的FRAM内这个框架

可能有人给我一些见解，以什么可能导致此赛格故障（堆栈损坏？）？通常gdb给我的程序中的行号，但这次它没有。

来源

2013-02-26 Bonnie

你有机会访问你并不拥有的内存。除此之外，可能需要看代码！ – 2013-02-26 04:49:15

gdb输出表明您正在查看由不同二进制文件生成的核心文件。要调试你的应用程序，你可以在gdb中运行它（使用“gdb binary”，然后是“run”命令），或者使用像valgrind之类的东西。 – vanza 2013-02-26 04:50:17

绝对使用valgrind进行segfaults。 – matzahboy 2013-02-26 04:50:33

这里可能发生的是你已经损坏了堆栈。程序的很多状态（包括告诉你你在哪个函数中的所有堆栈帧）都驻留在堆栈中，所以一旦被覆盖，调试器只能处理损坏的信息。

这样做的一种常用方法是将声明为本地变量的缓冲区溢出为字符串，例如，

int main() 
{ 
    char buf[4]; 
    return func1(buf); 
} 

int func1(char* theBuf) 
{ 
    return func2(theBuf); 
} 

int func2(char* sameBufBackSomeplaceInTheStack) 
{ 
    sprintf(sameBufBackSomeplaceInTheStack, "The stack is doomed."); 
    return 0; 
}

结果可能会有所不同，但是我破坏堆栈看起来像这样在调试器我这样做后：

Program received signal EXC_BAD_ACCESS, Could not access memory. 
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 
0x0000000100000d00 in _mh_execute_header() 
(gdb) where 
#0 0x0000000100000d00 in _mh_execute_header() 
#1 0x0000000000000000 in ??() 
(gdb)

反正，某处某处你的程序覆盖堆栈，这往往是挑战去调试...

来源

2013-02-26 05:11:38 wilsonmichaelpatrick

为什么我会遇到seg故障？

回答

相关问题