排查一个死机问题，搞了好几天时间，最终确定原因；最终确定问题原因，在此分享一下；
第一步：常规根据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，看系统配置）会导致这个潜在问题；