码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2017-09-22 22:41:47      阅读:517      评论:0      收藏:0      [点我收藏+]

标签:检查   传递   测试环境   影响   调用   logfile   消息   sock   centos   

现象:

         某个线上的服务最近频繁崩溃。该服务使用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 1s 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 stackd, mallocd or (recently) freed

 

前面的信息:”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/267https://github.com/alanxz/rabbitmq-c/issues/168

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

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

标签:检查   传递   测试环境   影响   调用   logfile   消息   sock   centos   

原文地址:http://www.cnblogs.com/gqtcgq/p/7577238.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!