状况简述:
程序采用Reactor模型, IO线程专做IO事件读写, 以及请求的dispatch分发, 后端线程池用于业务的同步操作. 对libcurl的使用, 也穿插在多线程中.
当程序功能完成后, 对其进行压力测试. 过了大致20分钟, 程序crash并出core.
gdb调core后, 发现其在epoll_wait之上的调用栈出问题了.
根据经验, 本着谁肇事, 谁擦屁股的原则, 对该线程以及epoll调用方做了艰苦卓绝, 却步履维艰的排查. 后面的事实证明, 这是条不归路, duang duang duang.....
逆向推测:
起初的排查没有效果, 于是乎, 采用逆向思维. 从SIGABRT 6信号出发, 看看什么情况下能触发该信号.
指针的重复删除会引发该错误, 如下面例子:
其他的内存操作, 如野指针的使用, 越界, 往往对应的是SIGSEGV 11.
于是乎, 寻找疑似double delete的情况, 结果还是一无所获.
信号认识:
真相只有一个, 可惜在那里呢? 是那个环节出错呢?
无意中, 再次扫了下堆栈, 徒然发现 <signal handler called>
看来epoll_wait的线程, 是被信号中断, 并执行了该信号回调函数(其来源标明了libcurl.so.4), 并在该信号处理函数中出SIGABRT 6.
让我们回忆下, 信号的处理.
raise函数, 会把信号发送给本线程. 而其他函数(如kill, alarm), 向进程发送信号, 但具体执行该信号处理函数的线程是不确定的.
现在离真相已经很接近了: 某线程触发信号, epoll_wait线程则执行了该信号处理函数, 可惜在这个处理函数中, 出了异常. 和epoll_wait无关, 与其调用方也没关系.
那某函数(黑衣人)是谁呢? 和libcurl有关系不?
拨开云雾:
通过搜索引擎, 发现"libcurl 多线程使用注意事项", "Libcurl多线程crash问题" 这两篇文章.
真相终于浮现出来了, 原来libcurl的超时机制默认是通过信号sigalrm, setjmp/longjmp函数来实现的, 在多线程情况下, 会导致程序crash.
这官方的说明, 也解释了core栈上的异常信息.
最终的解决方案就是, CURLOPT_NOSIGNAL设置为1.
curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1L);
总结:
甲方虐我千百遍, 我待甲方如初恋. 虽然被libcurl坑, 但对信号的理解更深刻了, 终是好事. 但C/C++和Java实现同样的业务功能时, C/C++ Coder需要了解更多的细节, 抬高门槛的同时, 也增加开发难度和开发时间, 未免有点得不偿失. 这篇文章不是语言之争, 就此打住.
写在最后：
如果你觉得这篇文章对你有帮助, 请小小打赏下. 其实我想试试, 看看写博客能否给自己带来一点小小的收益. 无论多少, 都是对楼主一种由衷的肯定.
