棧溢位問題分析

近日，程式總是莫名其妙的coredump，而且還是在變數定義的時候（如 int a=1），百思不得其解。在這種情況下，只有幾種情況可能出現：記憶體踩踏、棧溢位。

在經過長時間的分析確認，肯定不是記憶體踩踏。剩下的就是棧溢位了。linux下一般單個程式棧大小為10m，可用ulimit -s查閱。一般情況下，10m的大小足夠用，怎會出現棧溢位。再次對**進行了詳細的分析，發現有一處臨時變數的結構竟然有2m之巨。此處確實難以理解，為何採用如此大的結構體。可能是考慮到動態分配記憶體用不好容易導致記憶體洩漏，因此採用臨時變數。另外該函式又被遞迴呼叫兩次，因此該函式就耗用接近5m的棧空間。將該結構體改為指標後，該問題即解決。

解決該問題後，過了一段時間又出現了該問題，耗費較長時間後，最終確定又是棧溢位導致的。

tar -xvzf  libsigsegv-2.11

.tar
.gzcd libsigsegv-2.11
./configure
make
make install

a.在主程式新增如下

//載入標頭檔案

#include "sigsegv.h"
#ifndef sigstksz
# define sigstksz 1116384
#endif
//棧溢位後處理函式
void stackoverflow_handler (int emergency, stackoverflow_context_t scp)

char mystack[sigstksz];

stackoverflow_install_handler (&stackoverflow_handler,mystack, sizeof (mystack));

3.編譯鏈結庫，加上-lsigsegv。

當出現棧溢位時，將呼叫棧溢位函式，並退出程式，。

示例：

//stack_overflow.c

#include 
#include 
#include "sigsegv.h"
int times=0;
void stack_test()
}void stackoverflow_handler (int emergency, stackoverflow_context_t scp)
#ifndef sigstksz
# define sigstksz 1116384
#endif
int main()
#if 0
編譯：gcc -o stack -g -o2 stack_overflow2.c -lsigsegv
#endif

...

times=392729
times=392730
times=392731
times=392732
times=392733
times=392734
times=392735
times=392736
times=392737
stack overflow caught.

linux 管道溢位問題分析

由於專案中的執行緒間通訊使用到libuv中的pipe，由於libuv的高效能非同步結構，資料傳輸速度很快。為了方便資料解析試用了結構體，比如 typedef struct a a 1024 10 可以看到乙個資料報有10kb，在系統中檢視系統管道大小 pipe buf 大小 512 8 4kb，那豈...

記憶體和棧溢位問題定位

記憶體使用率在90 以上，通過監控工具apm檢視到一台虛擬機器上應用頻繁在發生了全域性gc fullgc 導致應用假死，不在接受請求。此時登入虛擬機器 使用mat分析dump檔案 參考資料 現象 乙個後端服務，每天都出現程序死掉。並且部署了該應用的後端服務都發生過程序死掉，通過監控apm發現，每次程...

ARM 堆疊溢位問題

今天一大早就有個師弟在qq上問了我乙個問題,先把 貼出來.softwareinterrupt stmfd sp mov r1,sp mrs r3,spsr tst r3,t bit thumb mode ldrneh r0,lr,2 yes,fetch swi no.in thumb mode bi...