一、问题背景
最近和一个厂家合作开发产品,我这边给出业务SDK,厂家进行底层实现。设备包括编译链这种都是厂家提供,我把SDK编译成动态库给厂家打包固件使用。
在后面厂家开发过程中提了一个段错误的bug,按照他们提供的固件包开始调试,确实是一个必现的段错误。
二、调试步骤
- 用gdb看下堆栈情况,然后看下代码位置。
通过堆栈信息和代码可以发现,xmlparser_destroy 这个函数的入参是个局部变量,等到进入函数内部的时候,指针
x
本应该指向入参的内存地址,但是却出现了奇怪的地址0x258
,这边段错误的原因也很显然了,就是x
指向的地址是不可访问的,判断i < x->iAttrCnt
时,导致了程序崩溃。至于这边x
指向的地址为什么被修改了,我猜测可能是某个地方内存越界导致的栈数据被修改。
- 审阅代码
段错误是很让人头疼的问题,如果是出错位置导致的段错误还好说。像这种只是出错位置触发到段错误,实际造成错误的地方在别处可能就需要花费很长时间去排查。查代码自然是必要的,前前后后的代码都查了一遍,确实没发现什么问题。排除了代码的问题。
- 与厂家沟通
既然自己这边暂时查不出问题,就有理由怀疑是厂家程序导致的内存越界,修改了我这边的数据。但是几次沟通下来也没有什么收获。然后我在调试的时候某次命令输入错误,导致厂家应用程序的模块部分没有起来,我们SDK的业务竟然都正常了,这更让我深信是厂家的程序导致的问题了,于是还是让厂家排查他们的程序有无问题。
- 查看程序运行信息
在厂家排查问题的时候,我也重新审视下自己的程序。通过打印日志的方式,把出错前后的一些变量地址打印出来,这样就导致了之前的段错误没了,但是出现了另一个异常,就是通过TCP发送的数据,其中几个字节被篡改了。不用说,肯定还是内存越界导致的。
- 按模块屏蔽代码
最后又试了下屏蔽部分代码试试,发现是可行的。我们的TCP发送是封装了个函数的,先用
select
判断套接字是否可写,然后再发送,打印了一下select
的返回值,和TCP套接字的文件描述符,套接字比较正常,是1500,但是返回值很异常,这边其实只监控一个文件描述符,select
的返回值却是100+(每次不太一样,但都远远大于1,这边正常应该返回准备好的文件描述符数量才对),我把select
相关处理语句给注释掉,直接调用send
发送数据,然后整个功能就正常了。
- 定位到问题
通过之前的一些尝试,可以判断
select
这块出现问题了,先看了下 select.h 中fd_set
这个结构体定义,如下所示:
然后分别看下 __FD_SETSIZE 和 __NFDBITS
__FD_SETSIZE 定义在 typesizes.h 头文件里
看到这边,隐约觉得哪里有问题,还记得之前我看到的使用的TCP套接字的文件描述符为1500+,这边才1024,先改一个比较大的值,编译后看看结果,然后就正常了,好坑爹的问题。
最后还是查一下问题出在哪里,看了下FD_SET
的定义
到这里基本上真相大白了,FD_SET
第一个参数如果大于等于__FD_SETSIZE
,即套接字文件描述符大于等于__FD_SETSIZE
,会导致fd_set
中的__fds_bits
数组越界。
三、结论
修改 bits\typesizes.h 中的 __FD_SETSIZE
,使其大于程序中所用到的文件描述符的最大值。
四、总结
其实刚开始的时候有去使用 ulimit -n 看下文件描述符的限制,但不是程序运行的环境,后来厂家说程序运行之前他们会执行下 ulimit -n 5120。而后来再调试的时候,因为输错命令导致厂家模块部分没起来的时候是没有使用 ulimit -n 5120 修改文件描述符的限制的,那时候程序正常了应该往 TCP 套接字这块去排查问题,这样不至于浪费后面的时间。总的来说还是知识储备不够,以后还是多读书,多看报。