标签:检查 传递 测试环境 影响 调用 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 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。
标签:检查 传递 测试环境 影响 调用 logfile 消息 sock centos
原文地址:http://www.cnblogs.com/gqtcgq/p/7577238.html