Select 使用不當引發的core，你應該知道的

排查乙個宕機問題，搞了好幾天時間，最終確定原因；最終確定問題原因，在此分享一下；如下rip不正確，指令位址錯亂，棧資訊已破壞；在此基礎上準確定位非常困難，但是仍可發現一些線索；

根據當前棧資訊，大概尋找到懷疑的函式

檢視整個棧上下資訊，看有無懷疑的函式：

所以很有可能就是fetchnsaddrev函式導致，需要重點關注；

更深入的細節，限於彙編不深入，比較難分析，不過可以有另外途徑；

-fstack-protector：

啟用堆疊保護，不過只為區域性變數中含有 char 陣列的函式插入保護**。

-fstack-protector-all：

啟用堆疊保護，為所有函式插入保護**。

詳細參見：

復現後，棧結構如下：

這個棧結構，看著比較爽了； asyncconnect返回時stackcheck檢查棧溢位了；

第三步、審查**，所以重點排查該函式：

先貼下**

}幾個人審查**，看了好久，沒有發現該函式有什麼問題；

進步檢視日誌發現有大量的select超時的列印，而且core掉時，必然在超時事件之後，此時懷疑select呼叫是否會出問題；因此，首先修改select為epoll呼叫進行測試，問題不能復現了；

@福巴找到核心**檢視select相關實現；

當n值超過1024上限就會導致設定到陣列之外，篡改掉記憶體；

fd_set(m_nsockfd, &rset); 在m_nsockfd超過1024時，會導致rset陣列越界，篡改後續記憶體；這也佐證了為什麼select很多超時錯誤，因為m_nsockfd大小越界，沒有落在select監聽的套接字集合內；

從oss環境上看，壓測時，有大量連線併發處理，所以在壓測時才最終發現該問題；

所有使用select系統呼叫的**應提高警惕，系統使用的套接字超過預設配置的（1024，看系統配置）會導致這個潛在問題；

Select 使用不當引發的core，你應該知道的

排查乙個宕機問題，搞了好幾天時間，最終確定原因 最終確定問題原因，在此分享一下 如下rip不正確，指令位址錯亂，棧資訊已破壞 在此基礎上準確定位非常困難，但是仍可發現一些線索 根據當前棧資訊，大概尋找到懷疑的函式 檢視整個棧上下資訊，看有無懷疑的函式 所以很有可能就是fetchnsaddrev函式導...

記錄一次由於執行緒使用不當引發的血案

最近給第三方做了乙個介面，介面的作用是接收資料對資料進行驗證之後通過kafka推送到模型進行資料處理，最終通過kafka接收模型的資料，開始只做了乙個非同步的介面，由於對方業務原因需要乙個同步的介面傳輸資料，但是每當執行一段時間之後程式就會進入假死狀態，介面無法正常呼叫 同步介面的實現是使用阻塞ma...

c thread 使用不當導致的崩潰問題

看個例子 1 class ctimer7 開始8void start 914 15void run 1622 23 結束24 void stop 2532 33 private 34 std thread t 35 std thread t1 36int i 37 bool b exit 38 39...