一、问题背景
????最近和一个厂家合作开发产品，我这边给出业务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_set中的__fds_bits数组越界。
三、结论
????修改 bits\typesizes.h 中的 __FD_SETSIZE，使其大于程序中所用到的文件描述符的最大值。
四、总结
????其实刚开始的时候有去使用 ulimit -n 看下文件描述符的限制，但不是程序运行的环境，后来厂家说程序运行之前他们会执行下 ulimit -n 5120。而后来再调试的时候，因为输错命令导致厂家模块部分没起来的时候是没有使用 ulimit -n 5120 修改文件描述符的限制的，那时候程序正常了应该往 TCP 套接字这块去排查问题，这样不至于浪费后面的时间。总的来说还是只是储备不够，以后还是多读书，多看报。