排查一个死机问题，搞了好几天时间，最终确定原因；最终确定问题原因，在此分享一下；
第一步：常规根据core文件查看栈信息，gdb –c core xxxx
如下rip不正确，指令地址错乱，栈信息已破坏；在此基础上准确定位非常困难，但是仍可发现一些线索；
根据当前栈信息，大概寻找到怀疑的函数
查看整个栈上下信息，看有无怀疑的函数：
所以很有可能就是fetchNSAddrEv函数导致，需要重点关注；
更深入的细节，限于汇编不深入，比较难分析，不过可以有另外途径；
第二步：因为core是能复现出来，所以思路是重新编译版本，增加编译选项-fstack-protector
-fstack-protector：
启用堆栈保护，不过只为局部变量中含有 char 数组的函数插入保护代码。
-fstack-protector-all：
启用堆栈保护，为所有函数插入保护代码。
详细参见：http://www.cnblogs.com/napoleon_liu/archive/2011/02/14/1953983.html
复现后，栈结构如下：
这个栈结构，看着比较爽了； AsyncConnect返回时stackcheck检查栈溢出了；
第三步、审查代码，所以重点排查该函数：
先贴下代码
int CHttpHandler::AsyncConnect(const char * pszIpAddr, unsigned short usPort, float fSelectTimeout, const std::string& host)
{
if (strlen(pszIpAddr) > 16)
{
SetErrMsg("invalid ip format, pszIpAddr=%s", pszIpAddr);
return -1;
}
m_nSockFD= socket(AF_INET, SOCK_STREAM, 0);
m_fSelectTimeout= fSelectTimeout;
if (m_nSockFD < 0)
{
SetErrMsg("init socket error, m_nSockFD=%d", m_nSockFD);
return -2;
}
// set nonblock
int flags = fcntl(m_nSockFD, F_GETFL, 0);
if (fcntl(m_nSockFD, F_SETFL, flags | O_NONBLOCK) < 0)
{
close(m_nSockFD);
m_nSockFD = -1;
SetErrMsg("set sock nonblock error");
return -3;
}
// set server ip, port
struct sockaddr_in serv_addr;
socklen_t addr_len;
bzero(&serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
inet_aton(pszIpAddr, &serv_addr.sin_addr);
serv_addr.sin_port = htons(usPort);
addr_len = sizeof(serv_addr);
//memset(m_szIPAddr, 0, 17);
memset(m_szIPAddr,0,sizeof(m_szIPAddr));
if(!host.empty())
{
if(host.length()>sizeof(m_szIPAddr)-1)
{
SetErrMsg("hostName too long ,hostName=%s,hostLen=%d,max_len=%d\n",host.c_str(),host.length(),sizeof(m_szIPAddr));
return -9;
}
memcpy(m_szIPAddr, host.c_str(), host.length());
}
else
{
memcpy(m_szIPAddr, pszIpAddr, strlen(pszIpAddr));
}
/*linger m_sLinger;
m_sLinger.l_onoff = 1;
m_sLinger.l_linger = 0;
setsockopt(m_nSockFD, SOL_SOCKET,SO_LINGER,(const char*)&m_sLinger,sizeof(linger));*/
// connect
int nRetCode;
nRetCode = connect(m_nSockFD, (struct sockaddr *)&serv_addr, addr_len);
if (nRetCode < 0)
{
if (errno != EINPROGRESS)
{
SetErrMsg("connect error, errno=%d", errno);
close(m_nSockFD);
m_nSockFD = -1;
return -4;
}
}
if (nRetCode == 0)
{
;
}
else
{
//warning oss find select cause crash while select timeout
fd_set rset, wset;
FD_ZERO(&rset);
FD_SET(m_nSockFD, &rset);
wset = rset;
struct timeval tv;
tv.tv_sec = (int)m_fSelectTimeout;
long usec = int ((m_fSelectTimeout - (int)m_fSelectTimeout)*1000000 );
tv.tv_usec = usec;
nRetCode = select(m_nSockFD + 1, NULL, &wset, NULL, &tv);
if (nRetCode == 0)
{
// timeout
SetErrMsg("connect error: select timeout, select retcode=%d ", nRetCode);
close(m_nSockFD);
m_nSockFD = -1;
return -5;
}
if ( FD_ISSET(m_nSockFD, &wset))//FD_ISSET(m_nSockFD, &rset) ||
{
int error;
socklen_t len = sizeof(error);
if (getsockopt(m_nSockFD, SOL_SOCKET, SO_ERROR, &error, &len) < 0)
{
SetErrMsg("connect error: getsockopt");
close(m_nSockFD);
m_nSockFD = -1;
return -6;
}
if (error)
{
SetErrMsg("connect error in select operation, error=%d", error);
close(m_nSockFD);
m_nSockFD = -1;
return -7;
}
}
else
{
SetErrMsg("connect error");
close(m_nSockFD);
m_nSockFD = -1;
return -8;
}
}几个人审查代码，看了好久，没有发现该函数有什么问题；
第四步：检查日志及系统配置
进步查看日志发现有大量的select超时的打印，而且core掉时，必然在超时事件之后，此时怀疑select调用是否会出问题；因此，首先修改select为epoll调用进行测试，问题不能复现了；
五、如此，加深怀疑slecect相关处理
@福巴找到内核代码查看select相关实现；
当n值超过1024上限就会导致设置到数组之外，篡改掉内存；
FD_SET(m_nSockFD, &rset); 在m_nSockFD超过1024时，会导致rset数组越界，篡改后续内存；这也佐证了为什么select很多超时错误，因为m_nSockFD大小越界，没有落在select监听的套接字集合内；
从OSS环境上看，压测时，有大量连接并发处理，所以在压测时才最终发现该问题；
六、总结：
所有使用select系统调用的代码应提高警惕，系统使用的套接字超过默认配置的（1024，看系统配置）会导致这个潜在问题；