select引起的服务端程序崩溃问题

现象：

         某个线上的服务最近频繁崩溃。该服务使用C++编写，是个网络服务端程序。作为TCP服务端，接收和转发客户端发来的消息，并给客户端发送消息。该服务跑在CentOS上，8G内存。线上环境中，与客户端建立的TCP连接大约在3~4万左右。

使用GDB查看每次崩溃产生的core文件，发现崩溃时的函数调用栈每次都各不相同，而且有时会发生在比较奇怪的地方，比如标准库std::string的析构函数中。

         该线上服务崩溃之后，会有监控进程进行重启，因此暂时不会造成太大的影响。

 

复现：

先尝试在自己的虚拟机环境中复现，考虑到虚拟机环境资源有限，如果无法复现则尝试在测试环境中复现。

 

首先编写模拟的客户端程序，该客户端程序需要尽可能地模拟实际客户端的所有动作：能够发送实际客户端所有可能发送的消息，并且会在随机的时间内向服务端建链和断链，该客户端是一个死循环后台程序，不断的重复建链、发消息、断链这一过程。

客户端程序写好之后，为了模拟线上环境中大量TCP连接的情况，编写一个脚本，循环启动多个客户端程序。

因虚拟机资源有限，先启动1000个客户端，也就是建立1000个TCP连接。结果崩溃未能复现。考虑可能还是连接数太少，改为1500个，这之前需要先调整Linux系统的最大打开文件数的限制，该限制默认是1024，调为102400。

启动1500个客户端，运行一段时间后，崩溃出现了！

 

查找原因：

         考虑到崩溃问题大部分都是因为内存问题引起的，因此尝试使用valgrind工具查找崩溃原因。

valgrind是一套Linux下的仿真调试工具集合，其中的memcheck工具是检查内存问题的利器，它能够检查C/C++中的内存问题有：

内存泄露；

访问非法的内存地址，比如堆和栈之外的内存，访问已经被释放的内存等；

使用未初始化的值；

错误的释放内存，比如重复释放，错误的malloc/new/new[]和free/delete/delete[]匹配；

memcpy()相关函数中的dst和src指针重叠；

申请内存时传递给分配函数错误的size参数；

 

使用valgrind启动服务端程序，命令如下：

valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes /path/to/service -c /path/to/service/configfile > /path/to/logfile 2>&1 &

 

“--tool=memcheck”表示使用内存检查工具memcheck；

”--leak-check=full --show-leak-kinds=all”表示检查并列出所有类型的内存泄露信息；

“--track-origins=yes”表示列出所有使用未初始化值时的信息；

“/path/to/service -c /path/to/service/configfile > /path/to/logfile 2>&1”表示启动服务端程序，并将所有标准输出和标准错误输出都重定向到/path/to/logfile中。

 

         使用valgrind启动服务端程序，然后启动1500个客户端，崩溃很快就出现了。查看日志文件，发现了下面的信息：

==4663== Syscall param select(writefds) points to uninitialised byte(s)
==4663==    at 0x5D6DBD3: ??? (in /usr/lib64/libc-2.17.so)
==4663==    by 0x584984: Socket::WaitToWrite(int) (socket.cpp:553)
==4663==    by 0x583FC7: Socket::TimedSend(char const*, int, int, bool) (socket.cpp:251)
...
==4663==  Address 0x1ffeffeff0 is on thread 1's stack
==4663==  in frame #1, created by Socket::WaitToWrite(int) (socket.cpp:547)

...

==4663== Invalid write of size 4
==4663==    at 0x583FC8: Socket::TimedSend(char const*, int, int, bool) (socket.cpp:251)
...
==4663==  Address 0x4001ffefff05c is not stack'd, malloc'd or (recently) free'd

 

前面的信息：”Syscall param select(writefds) points to uninitialised byte(s)”说明select系统调用中的writefds参数指向了未初始化的内存，内存地址是0x1ffeffeff0，该地址在线程1的栈中；

         后面的信息：”Invalid write of size 4”表示一个非法的内存写操作，写入的地址0x4001ffefff05c既不是栈上的地址，也不是malloc申请的堆上地址。这就是造成崩溃的原因了。

 

         根据valgrind给出的信息，查看源代码，这里的函数调用关系是Socket::TimedSend->Socket::WaitToWrite->select。在Socket::WaitToWrite函数中，调用select部分的代码是：

fd_set writeSet;
FD_ZERO(&writeSet);
FD_SET(m_hSocket, &writeSet);
timeval tv = { nTimeout / 1000, (nTimeout % 1000) * 1000 };
return select(m_hSocket + 1, NULL, &writeSet, NULL, &tv);

 

         这段代码就是监控描述符m_hSocket在nTimeout毫秒的时间内是否可写。到这里，基本已经知道出问题的原因了。原因就在于linux下select的限制造成的。

 

linux下的select限制

         select所使用的fd_set结构，本质上是一个固定长度的位数组。宏FD_CLR() 和 FD_SET()根据描述符的值，设置位数组中相应的位为0或为1，以此决定监控哪些描述符。在linux下，fd_set这个位数组固定为1024bit，也就是仅能处理值为0到1023的描述符。

         因此，当连接数越大时，服务端创建的描述符越多，描述符的值也就会越大。对于有上万连接的服务端而言，描述符的值肯定已远远超过1024。

         具体到代码中，如果m_hSocket这个描述符的值很大，则FD_SET根据其值设置writeSet位数组的相应位时，就是一个内存越界的写操作，对应于valgrind给出的信息：”Invalid write of size 4”。对于以万计的m_hSocket而言，这个写操作修改的很可能是其他函数栈的信息，因而崩溃时的函数调用栈各不相同且比较奇怪了。

         并且，select系统调用根据m_hSocket的值决定访问writefds的界限，m_hSocket的值很大的情况下，select系统调用也就访问到了writefds实际长度之后的内容，因而valgrind会打印：”Syscall param select(writefds) points to uninitialised byte(s)”

 

解决方法：

         在linux平台下，使用poll代替select。

 

总结：

         Linux下select的限制问题是网络编程中容易被忽视的坑，有一些很成熟的开源代码如redis和rabbitmq-c都曾遇到过这个坑：https://github.com/antirez/redis/issues/267、 https://github.com/alanxz/rabbitmq-c/issues/168。

         当前的网络环境下，连接数上万是很稀松平常的是，因此在Linux平台下的网络服务端程序中，应该尽量避免使用select，而改用poll或epoll。

转载于:https://www.cnblogs.com/gqtcgq/p/7577238.html