内存问题是C程序员永久的话题,也是最能让C程序员心痛的话题。内存bug即隐秘,危害又大,而且往往当你解决了它之后,你会发现你的错误是多么的低级。以我为例,看下面的两个case:
CASE1
背景: 配置信息读取
Bug现象: 通过打印语句观察到,在配置读取中间时刻,某一指针突然被置为NULL,出core。
耗时: 6小时
问题所在及分析: 经过6小时的不懈努力,终于发现了这一让我哭笑不得的低级错误。问题原因大致是这样的:
我定义了一个存储配置信息的结构体变量指针,并在初始化的时候给该指针在共享内存中分配空间,下面的代码就是我分配空间时的代码
xx_t *p;
…//
p = xx_malloc((void**)&p, sizeof(p));
正确的代码
p = xx_malloc((void**)&p, sizeof(xx_t));
我想我之所以花了那么长时间才找到这个问题,是被一些奇怪的现象所蒙蔽了,也是查找内存误操作问题经验不足所致。
CASE2
背景: Ftp客户端获取文件列表
Bug现象: 当Server端目录下文件个数很多时(如>=1000),以后的ftp操作全部失效,出现errno = 95、134等。
耗时: 7小时
问题所在及分析: 由于在文件少的时候,我们的ftp client工作一切正常,所以我们最开始怀疑的是接收数据缓冲区开得不够大。但是在加大缓冲区之后,问题依然存在。由于对FTP协议并不是很熟悉,导致在一些细节上又耽误了很多时间。之后我们看到一个奇怪的现象就是errno 95的出现,说明我们的ctrl channel socket已无效。我们使用最传统的调试方法使用打印语句,从创建Ctrl Socket开始,一直追踪到问题发生区域,并锁定一块区域的代码,在该代码之前ctrl socket为31, 之后ctrl socket居然变为1, 而且这段代码中并没有操作socket的语句。我们分析有两个可能:
1)这段代码运行时间过长,导致Ftp server关闭link;
2)该段代码有内存误操作,导致内存被污染;
我们使用排除法,首先注掉那段代码,取而待之的是sleep(30),我们想如果sleep 30秒,Ftp server不关闭link的话,那么就是第2种可能了,结果是的确有“内存误操作”,静态检查代码后,锁定在一个给指针数组赋值的语句上,察看上层代码后,发现这就是问题所在。用代码说明问题大致是这样的:
char *flist[200];
…//
int cnt = 0;
while (读取数据不为空) {
p = malloc(…);
…//
flist[cnt] = p;
cnt++;
}
显然如果数据超过200条,数组必然越界。
总结:经过两个Case中,发现自己在找“内存误操作”问题上的经验不足,但同时经过这两个case,我总结一下几条,可能对以后的bug查找有所帮助。
a) 虽然“内存bug”不易查找和修改,但是一定要摆正心态,首先确定是“内存误操作”带来的bug;
b) “内存bug”绝大多数是极其低级的错误,所以首先要仔仔细细静态检查代码,可以按下面的顺序检查
.搜索所有的malloc, memset, memcpy一类的内存操作函数,察看是否有“马虎”错误;
.察看所有的数组变量,看是否有越界嫌疑
c) 打印语句是最简单,但是却是最有效的debug方法(我是这么认为的^_^),要利用好哟。
[注]:errno 95 — Socket operation on non-socket
评论