前言

相信無論大佬還是小白，都在開發中遇到過棧溢出的問題，而且因為沒有明確日志，難以定位問題的根源。Stack Overflow 社區的命名也由此而生，而到現在雖然Stack Overflow因為大模型已經幾乎要涼涼了，但是棧溢出的問題仍然困擾著許多開發者。

正好RT-Trace發布了他們的內測新功能——棧保護，與此同時，采集時長也有了大幅提升，在我的板子上甚至可以穩定采集 三分鐘。那我們就來看看他的效果和實用性吧。

測試環境

星火一號開發板

rt-trace工具

使用方法和效果

可以看到使用方法順延了先前trace功能的配置界面，加上了兩個框，來選擇需要保護的線程和需要被保護的棧底空間大小，使用起來還是很簡單的

配置成功后就可以去trace_view界面測試了，這里我星火一號上跑了一個遞歸爆棧測試程序，沒有優化

#include#include#include#ifndefRT_USING_NANO#include#include#include#include#endif/* RT_USING_NANO */rt_thread_tstack_thread =NULL;#defineTHREAD_PRIORITY 25#defineTHREAD_STACK_SIZE 512#defineTHREAD_TIMESLICE 5intmain(void){ while(1) { rt_thread_mdelay(500); }}#defineMAX_RECURSION_DEFAULT 5 // 默認最大遞歸次數staticintmax_recursion = MAX_RECURSION_DEFAULT;// 可控制的最大遞歸次數void*get_stack_top_addr(){ return(void*)((uint32_t)stack_thread->stack_addr + stack_thread->stack_size);}void*get_stack_bottom_addr(){ return(void*)((uint32_t)stack_thread->stack_addr);}/*** 遞歸棧溢出測試函數* 每次遞歸僅創建一個32位變量* @param depth 當前遞歸深度*/voidrecursive_stack_overflow(intdepth){ volatileuint32_ta =0x12345678;// 創建一個32位變量并賦值 staticvoid*last_a_addr =NULL; // 獲取棧邊界地址 void*stack_bottom_addr =get_stack_bottom_addr(); void*stack_top_addr =get_stack_top_addr(); if(depth !=1) { uint32_tstack_used = (uint32_t)last_a_addr - (uint32_t)&a; rt_kprintf("[Depth:%2d] var_a addr:0x%08X,stack_used: %d\n ", depth, &a, stack_used); } else { rt_kprintf("[Depth:%2d] var_a addr:0x%08X\n ", depth, &a); } // 終止條件：達到最大遞歸次數 if(depth >= max_recursion) { rt_kprintf("[Depth:%2d] 已達到最大遞歸次數 %d，終止遞歸\n", depth, max_recursion); return; } last_a_addr = (void*)&a; // 短暫延遲，便于觀察輸出 rt_thread_mdelay(10); // 遞歸調用 recursive_stack_overflow(depth +1);}/*** 棧保護線程入口函數* @param p 線程參數*/voidstack_protect_thread(void*p){ // 獲取棧信息 void*stack_bottom_addr =get_stack_bottom_addr(); void*stack_top_addr =get_stack_top_addr(); uint32_tstack_size = stack_thread->stack_size; // 打印線程啟動信息 rt_kprintf("線程啟動:\n"); rt_kprintf(" 棧底地址: 0x%08X\n", stack_bottom_addr); rt_kprintf(" 棧頂地址: 0x%08X\n", stack_top_addr); rt_kprintf(" 棧大小: %d 字節\n", stack_size); rt_kprintf(" 最大遞歸次數: %d\n", max_recursion); rt_kprintf("----------------------------------------\n"); rt_thread_mdelay(20); // 開始遞歸測試 recursive_stack_overflow(1); rt_kprintf("----------------------------------------\n"); rt_kprintf("遞歸測試結束\n");}/*** 設置最大遞歸次數（外部可調用）* @param count 最大遞歸次數，<=0 則使用默認值?*/void?set_max_recursion(int?argc,?char?**argv){? ? int?count =?atoi(argv[1]);? ? if?(count <=?0)? ? {? ? ? ? max_recursion = MAX_RECURSION_DEFAULT;? ? ? ? rt_kprintf("已設置最大遞歸次數為默認值: %d\n", MAX_RECURSION_DEFAULT);? ? }? ? else? ? {? ? ? ? max_recursion = count;? ? ? ? rt_kprintf("已設置最大遞歸次數為: %d\n", max_recursion);? ? }}MSH_CMD_EXPORT(set_max_recursion, 設置最大遞歸次數(參數為次數));/**?* 創建棧保護測試線程?*/void?create_stack_protect_thread(void){? ? // 創建線程（棧大小2048字節）? ? stack_thread =?rt_thread_create(? ? ? ? "stack_thread", ? ? ? // 線程名稱? ? ? ? stack_protect_thread,?// 入口函數? ? ? ? RT_NULL, ? ? ? ? ? ? ?// 參數? ? ? ? 512, ? ? ? ? ? ? ? ? ?// 棧大小? ? ? ? 20, ? ? ? ? ? ? ? ? ? // 優先級? ? ? ? 10? ? ? ? ? ? ? ? ? ? // 時間片? ? );? ? if?(stack_thread != RT_NULL)? ? {? ? ? ? rt_thread_startup(stack_thread);? ? ? ? rt_kprintf("棧保護線程創建成功\n");? ? }? ? else? ? {? ? ? ? rt_kprintf("棧保護線程創建失敗\n");? ? }}MSH_CMD_EXPORT(create_stack_protect_thread, 創建棧保護測試線程);

經過遞歸三次，五次，八次（第八次溢出）的測試后，捕獲到的trace圖像是這樣的

0-4s 和 0-8s 遞歸三次以及遞歸五次，都沒有踩到我們的報警閾值

8-12s 遞歸八次時，在第6次踩到我們的64字節報警線

msh />create_stack_protect_thread棧保護線程創建成功msh />線程啟動: 棧底地址:0x20004160 棧頂地址:0x20004360 棧大小: 512字節 最大遞歸次數:10----------------------------------------[Depth: 1] var_a addr:0x20004330[Depth: 2] var_a addr:0x20004310,stack_used:32[Depth: 3] var_a addr:0x200042F0,stack_used:32[Depth: 4] var_a addr:0x200042D0,stack_used:32[Depth: 5] var_a addr:0x200042B0,stack_used:32[Depth: 6] var_a addr:0x20004290,stack_used:32[Depth: 7] var_a addr:0x20004270,stack_used:32[Depth: 8] var_a addr:0x20004250,stack_used:32[E/kernel.sched] thread:stack_tstack overflow

從上面的調試日志可以看到，棧溢出前64字節，正好是第六次遞歸的時候，這說明這個棧溢出報警起碼準確度沒問題。

但是細心的小伙伴可能發現了另一個問題，距離棧底似乎還有很大的空間，但是棧溢出“提前發生了”，我們的報警也提前了。這是因為我們的遞歸函數中調用了其他的函數，經過調試發現，造成棧溢出的直接原因是rt_thread_mdelay，最后棧溢出時，第八次遞歸進入后，sp位置在0x20004240，而調用rt_thread_mdelay最大深度能到0x2000412c，此時已經遠遠超過了我們的棧底，所以溢出和警報都是正常的。

總結

體驗下來，rt-trace的棧保護功能確實能很好的提示我線程棧的使用情況，可調的閾值也給了用戶比較大的自由度，這次的升級trace的采集時間也大大加長了，之前只能采12秒，現在可以以分鐘為單位進行采集。

不過還是有些可以繼續提升的部分，比如現在的棧保護只能保護一個線程，如果能實時自動保護所有的線程，可能使用的體驗和帶來的幫助會更好。