之前的那個程式異常退出的問題一直還是不好查詢，奇怪的地方是在core檔案中看到的堆疊資訊始終都是錯誤的資訊，引數位址指向的都是不正確的地方。然而排查了很長時間之後，也未發現有溢位的地方出現。
擱置一段時間之後，突然就想到乙個問題，我們的這個服務程式是使用intel的icc編譯器編譯的，那麼，會不會是因為icc編譯的二進位制檔案與gcc編譯器編譯出來的不一樣，導致在gdb除錯core檔案的時候不能正確識別堆疊位址？有了想法便開始驗證，修改了makefile檔案之後重新編譯程式，執行，壓測，異常退出，除錯，反覆幾次，排除了一些編譯器不同的語法問題後，終於堆疊資訊正常了，函式引數位址正確，引數值也都看得到了。
程式退出的地方定位到
fd_set(psocket, &writefds);
這一行。查詢資料得知，fd_set是配合select函式進行socket監聽使用的，由於核心限制，其監聽的檔案描述符（也就是socket）的值，不能大於__fd_setsize巨集定義的大小，在我們的系統中，這個值是1024.這就很明白了，我們的程式因為要建立大量的連線，socket大小超過1024是有可能的，在高併發的壓力測試情況下。這也是為什麼之前未發現問題的原因，以前的20路壓測不會觸發這個問題。於是將事件監聽從select改為epoll模型後重新測試，果然穩定了，不再出現異常退出的問題。
想起知乎上乙個對icc和gcc編譯器比較的回答中的一句話，icc雖然根據處理器特性對編譯器優化做得很好，但是，整個開源**體系的工具鏈都是用gcc，所以在排查問題的時候，icc編譯的二進位制檔案可能有些奇怪的地方，畢竟，gcc,g++,gdb啥的，他們才是一家的。
程式異常退出除錯
這周遇到乙個非常奇怪的事，程式在壓力測試的時候會莫名奇怪的掛掉，但是除錯時卻發現情況也是很詭異。使用gdb列印呼叫棧後發現，函式呼叫棧裡的this指標指向的值不對勁。credisclient connect this 0x603,ip port 4,timeout 1956863078 不僅如此，所...
android捕獲程式異常退出
今天看到迅雷動漫裡面乙個crashhandler 的類，我猜是崩潰處理類。進去一看。果然。順便學習一下。android系統的 程式異常退出 給應用的使用者體驗造成不良影響。為了捕獲應用執行時異常並給出友好提示，便可繼承 uncaughtexceptionhandler 類來處理。通過thread.s...
程式異常退出後自啟
在windows上，許多服務或者展示類的客戶端往往都會附帶開機自啟 程式異常退出後自啟這一功能。功能很簡單，實現起來也不複雜，只需要建立乙個監控程式來一直檢測其是否正在執行，沒執行則啟動它 開機自啟只需將程式路徑新增到登錄檔中即可。include stdafx.h include include i...