GDB - 确定分段错误的原因

gdb - identify the reason of the segmentation fault

本文关键字：错误 分段 GDB      更新时间：2023-10-16

我有一个在我的机器上运行良好的服务器/客户端系统。但它的核心转储到其中一个用户机器（操作系统：Centos 5）。由于我无法访问用户的计算机，因此我构建了一个调试模式二进制文件并要求用户尝试一下。在运行了大约 2 天后，崩溃确实再次发生。他把核心转储文件发给我。使用 gdb 加载核心转储文件，它确实显示了崩溃位置，但我不明白原因（对不起，我以前的经验主要是使用 Windows。我对 Linux/gdb 没有太多经验）。我希望得到您的意见。谢谢！

1. 用户计算机上的/var/log/messages 显示段错误：

1 月 16 日 09：20：39 LPZ08945内核： LSystem[4688]：段错误在 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

此消息指示指令指针 80e6433 和堆栈指针 f2afd4e0 处存在段错误。看起来程序尝试在地址 0 处读/写。

2. 将核心转储文件加载到 GDB 中，它会显示崩溃位置：

$gdb 磁芯.19009

GNU gdb （GDB） CentOS （7.0.1-45.el5.centos）

。（省略了GDB的许多输出行）

核心由"./LSystem"生成。

程序以信号 11 终止， 分段错误。

'#0' 0x080e6433 in CLClient：：connectToServer （this=0xf2afd898， conn=11） at liccomm/LClient.cpp：214

214 memcpy（（char *） & （a4.sin_addr）， pHost->h_addr， pHost->h_length）;

GDB说车祸发生在214号线？

3.帧信息。（在帧 #0）

（GDB） 信息框

堆栈级别 0，帧在 0xf2afd7e0：

eip = 0x80e6433 in CLClient：：connectToServer （liccomm/LClient.cpp：214）; 保存的 EIP 0x80e6701

在0xf2afd820按帧调用

源语言 C++。

Arglist at 0xf2afd7d8， args： this=0xf2afd898， conn=11

局部0xf2afd7d8，前一帧的sp是0xf2afd7e0

保存的寄存器：

EBX 在 0xf2afd7cc，EBP 在 0xf2afd7d8，ESI 在 0xf2afd7d0，EDI 在 0xf2afd7d4，EIP 在0xf2afd7dc

帧位于 f2afd7e0，为什么它与第 1 部分的 rsp 不同，即 f2afd4e0？我猜用户可能为我提供了不匹配的核心转储文件（其 pid 为 19009）和/var/log/messages 文件（指示 pid 4688）。

4. 来源

（GDB） 列表 +

209
210         //pHost is declared as struct hostent* and 'pHost = gethostbyname(serverAddress);'
211         memset( &a4, 0, sizeof(a4) );
212         a4.sin_family = AF_INET;
213         a4.sin_port = htons( nPort );
214         memcpy((char *) & (a4.sin_addr), pHost->h_addr, pHost->h_length);
215
216         aalen = sizeof(a4);
217         aa = (struct sockaddr *)&a4;

我看不出214行有什么问题。并且这部分代码必须在 2 天的运行时运行多次。

5. 变量

因为 gdb 表明 214 行是罪魁祸首。我打印了所有内容。

memcpy((char *) & (a4.sin_addr), pHost->h_addr, pHost->h_length);

（GDB） 打印a4.sin_addr

$1 = {s_addr = 0}

（gdb） 打印和 （a4.sin_addr）

$2 = （in_addr *） 0xf2afd794

（gdb） print pHost->h_addr_list[0]

$3 = 0xa24af30 "\202}\204\250"

（gdb） 打印 pHost->h_length

$4 = 4

（GDB） 打印内存

$5 = {} 0x2fcf90

所以我基本上打印了214行的所有内容。（"pHost->h_addr_list[0]"由于"#define h_addr h_addr_list[0]"而变为"pHost->h_addr"）

我没能发现任何错误。你抓到什么鱼腥了吗？内存是否可能在其他地方损坏？感谢您的帮助！

[已编辑] 6. 回溯追踪

（GDB） 英国电信

'#0' 0x080e6433 in CLClient：：connectToServer （this=0xf2afd898， conn=11） at liccomm/LClient.cpp：214

'#1' 0x080e6701 in CLClient：：connectToLMServer （this=0xf2afd898） at liccomm/LClient.cpp：121

。（第2~7帧省略，不相关）

'#8' 0x080937f2 in handleConnectionStarter （par=0xf3563f98） at LManager.cpp：166

"#9"0xf7f5fb41在？？()

"#10"0xf3563f98在？？()

"#11"0xf2aff31c在？？()

"#12"0x00000000在？？()

我遵循了嵌套的调用。他们是正确的。

memcpy 的问题在于源位置与目标位置的类型不同。

您应该使用 inet_addr 将地址从字符串转换为二进制 

a4.sin_addr = inet_addr(pHost->h_addr);

根据实现的不同，前面的代码可能无法正常工作（有些是我的返回struct in_addr，有些会返回unsigned long，但原理是一样的。

相关文章：