工作中遇到一次這樣的問題：棧上的空間不夠用了，導致stack overflow，程式crash，並且coredump被寫亂了。
這裡用小例子，記錄這樣的問題。
【**】
#include #include #include #include #define stack_buffer_size 10240
void * thread_func1(void * arg)
return 0;
}void * thread_func2(void * arg)
return 0;
}int main(int argc, char * argv)
【測試】
1.
g++ main.cpp -o t -lpthread
ulimit -s 20
./t
gdb t
(gdb) b main.cpp:11
(gdb) i threads
3 thread 0x7ffff7fe5700 (lwp 22751) 0x00007ffff71393bd in nanosleep () from /lib64/libc.so.6
* 2 thread 0x7ffff7ff9700 (lwp 22750) thread_func1 (arg=0x0) at main.cpp:12
1 thread 0x7ffff7fe7720 (lwp 22747) 0x00007ffff7bc80ad in pthread_join () from /lib64/libpthread.so.0
0x7ffff7fe7720 - 0x7ffff7fe5700 = 8224
直接執行 ./t，沒有crash
2.待續
記錄乙個BUG
vm版本 kali版本 centos 8 版本 vmtool版本 新裝的centos8 因為無法拖拽檔案到虛擬機器中，就重新裝了一下vmtool，安裝之後還是不行，開啟kali發現原本裝好的vmtool，現在也不能拖拽檔案了，就又在kali重灌了一次，還是不能拖拽，上網查了一下，在執行.vmware...
記錄乙個 lll lock wait
乙個dba同事昨天在執行乙個命令列工具的時候發現程式hang住，問題挺有意思，值得記錄下。首先用pstack看了下程式的呼叫棧，這是個多執行緒程式，pstack結果看到幾乎所有的執行緒都等在write呼叫上。如下是pt pmp的輸出結果 tue may 27 18 30 06 cst 2014 55...
記錄乙個高階BUG
偶然出現一次，差點額忘記，但是一旦出現，後患無窮，記錄一下。因為新程式會在任務中一直鳴叫，但是mqtt一直沒有看到裝置入網。看log，我的裝置沒有連線到正確的平台！思考 這個bin檔案是之前上傳到平台的，其間我已經修改了工程！因為cfg檔案是不變了，裝置會讀cfg獲得平台位址！也就是我cfg改了以後...