进程文件句柄数超过1024，使用select函数越界

问题场景

场景：客户的配置todb回库多实例时，启动服务时或者执行初始化时有较大的概率出现core，core内容如下

排查过程

1. 经分析排查（zhouds发现）：对象指针被改了，怀疑肯定是哪里存在越界导致内存被踩到

2. 使用内存检测工具valgrind运行todb插件获取core日志

valgrind --log-file=todb_val.log --tool=memcheck --leak-check=full --show-leak-kinds=all --trace-children=yes xxxxx -f todb_demo.xml -start todbsvr -t ar -s 0 -database demo -local_mode 1

经daiyh发现实际上出core应该发生在todb_work_thread.cpp:714行代码

3. 分析CTodbWorkThread::IsReadyToSync()代码，因为select的方式最多支持监听1024个句柄，怀疑两个地方

怀疑点1：FD_SET(m_iRedoFd, &fds) 可能出现越界；

怀疑点2：select()如果出现信号触发，可能存在越界；

select.h头文件见下图：（参考：深入解析为何select最多只能监听1024个）

4. 再次分析core，可以验证所有的core里面的 m_iRedoFd都超出1024：

     

5. 在测试环境下模拟出现core的场景：

      5.1 模拟前查看当前环境配置下，m_iRedoFd的值，可以看到当前环境下m_iRedoFd=38：

5.2 在todb的构造函数中打开多个句柄，构造句柄超出1024的情况：

5.3 启动后验证是否出现类似core

实际情况：程序启动时出现core，并且通过守护进程不断拉起和再次core如下：

查看Core的内容：可以看到，core的内容和用户环境的core极其类似

6. 进一步分析core的原因

6.1 使用gdb启动todb回库插件

6.2 设置watch观察this指针

6.3 验证 怀疑点1 ： 第一次被FD_SET出this指针没有被修改

关于why：因为this指针实际上存储在寄存器中，所以此处即便内存被破坏了，this指针仍然还能用，如下图，watch   &this 时提示如下：

6.4 触发watch：

6.5 继续往下走回到CTodbWorkThread::Run()

可以看到在743行，即CTodbWorkThread::IsReadyToSync()退出的时候，this指针被修改。

个人推测：

        1. 当程序在CTodbWorkThread::IsReadyToSync()函数内时，使用的一直是寄存器中的this指针，所以此时即便堆栈数据被破坏，仍然不影响当前函数的使用。

        2. 在CTodbWorkThread::IsReadyToSync()退出时，此时寄存器重新加载this指针，而此时加载到的this指针实际上被破坏了。

        3. 退回CTodbWorkThread::Run()函数时，函数在读m_bStop的成员变量时，因为this指针错误，导致读取失败和出core。

6.6 调试失败的core，可以看到出core确实出在todb_work_thread.cpp::266行，即6.5中分析到的读取m_bStop的位置。

结论

• 底层原因： fd_set最多只能支持1024个句柄，如果超出1024，FD_SET和select()不会检测越界
• 根本原因：CTodbWorkThread::IsReadyToSync()使用select()函数，且没处理好文件句柄超出1024的情况，导致堆栈被破坏
• 直接原因：todb使用多实例，导致进程文件句柄超出1024，触发程序中的缺陷
• 解决方案：建议使用epoll替换select()

其他学习：select的fd超过1024将会非常危险------FD_SET导致core dump

FD_SET 的实现：