這周遇到乙個非常奇怪的事，程式在壓力測試的時候會莫名奇怪的掛掉，但是除錯時卻發現情況也是很詭異。使用gdb列印呼叫棧後發現，函式呼叫棧裡的this指標指向的值不對勁。
credisclient::connect (this=0x603,不僅如此，所有引數的值都不對。當時就在想，是不是某個地方的操作導致記憶體溢位了，覆蓋了棧內容，於是就想順著呼叫棧一直往上找，看看是在哪個函式呼叫處出的問題，然而卻發現找到第乙個呼叫棧時，this指標和函式引數還是不對，更加讓人不解的是，所有的呼叫棧裡，使用info locals檢視變到的區域性變數的值都是正確的，這就表明，程式堆疊並沒有完全被破壞掉。而且，某些區域性變數的值是從函式引數裡算出來的，但是info args檢視引數就有問題，info locals檢視區域性變數就有問題。通過查詢資料，大概明白了可能原因，由於現在的cpu都擁有數量較多的暫存器，於是，一般的引數傳遞都是使用暫存器來進行的，中有介紹到：ip=, port=4,
timeout=-1956863078)
x86-64有16個64位暫存器，分別是：%rax，%rbx，%rcx，%rdx，%esi，%edi，%rbp，%rsp，%r8，%r9，%r10，%r11，%r12，%r13，%r14，%r15。其中：於是我就檢視了一下rdi, rsi, rdx幾個暫存器的值，果然這幾個暫存器的值全都有問題，怪不得所有的引數都看不見呢，估計是在什麼地方被寫壞了。由於對暫存器的了解不是很深入，只好放棄core檔案的除錯，直接開著gdb 執行程式進行壓測吧。這一開，發現%rax 作為函式返回值使用。
%rsp 棧指標暫存器，指向棧頂
%rdi，%rsi，%rdx，%rcx，%r8，%r9 用作函式引數，依次對應第1引數，第2引數。。。
%rbx，%rbp，%r12，%r13，%14，%15 用作資料儲存，遵循被呼叫者使用規則，簡單說就是隨便用，呼叫子函式之前要備份它，以防他被修改
%r10，%r11 用作資料儲存，遵循呼叫者使用規則，簡單說就是使用之前要先儲存原值
滿屏的建立新執行緒提示啊，檢視了下程序的執行緒數目，3000多呢，有時候能過萬。這太不正常了，不是使用執行緒池的嗎？聯想到以前20路壓測時沒出過問題，在100路壓測時就有了問題，應該可能是跟執行緒數量過多有關，於是查詢執行緒池相關的**，果然是有問題的，
只有增加執行緒，沒有刪除執行緒，怪不得執行緒數量會一直增加。
然而還是沒有找到程式異常退出的直接原因，但是得先將執行緒池這個地方的數量控制加上去再進行測試，這個問題還遠沒有結束，看來還得繼續找下去。。。
程式異常退出除錯 二
之前的那個程式異常退出的問題一直還是不好查詢，奇怪的地方是在core檔案中看到的堆疊資訊始終都是錯誤的資訊，引數位址指向的都是不正確的地方。然而排查了很長時間之後，也未發現有溢位的地方出現。擱置一段時間之後，突然就想到乙個問題，我們的這個服務程式是使用intel的icc編譯器編譯的，那麼，會不會是因...
android捕獲程式異常退出
今天看到迅雷動漫裡面乙個crashhandler 的類，我猜是崩潰處理類。進去一看。果然。順便學習一下。android系統的 程式異常退出 給應用的使用者體驗造成不良影響。為了捕獲應用執行時異常並給出友好提示，便可繼承 uncaughtexceptionhandler 類來處理。通過thread.s...
QT輸出除錯資訊
1 window下qt中用qdebug 輸出除錯資訊到console控制台的設定方法 2 qt輸出除錯資訊 在qt中輸出除錯資訊有四個函式，分別是 qdebug qwarning qcritical以及qfatal，從字面資訊上就可以看出，他們屬於不同的等級，由於這四個函式的使用都相似，所以這裡只選...