Re: [問題] Linux - Alignmet trap

看板C_and_CPP作者 (小風)時間14年前 (2009/12/02 04:32), 編輯推噓6(601)
留言7則, 7人參與, 最新討論串2/4 (看更多)
※ 引述《eleghost (徵求12/5五月天DNA門票!!)》之銘言: : 遇到的問題: (題意請描述清楚) : 程式執行一段時間(不固定, 一分鐘以下) 會出現 : Alignment trap: xxx(pid) PC=0x0001645 ..... : 來自kernel的錯誤訊息, 因為現在已經把成是盡量精簡.. : 但還是抓不出錯誤, 也用 addr2line 這個程式將PC所指出的 : function address印出, 但也是沒有幫助... : 請問要怎樣抓這類bug呢? 謝謝! : 希望得到的正確結果: : 程式跑出來的錯誤結果: : 開發平台: (例: VC++ or gcc/g++ or Dev-C++, Windows or Linux) : linux, gcc4 : 有問題的code: (請善用置底文標色功能) : 補充說明: PC 只是一個 Program Counter, 無法告訴你問題發生時, 執行到哪一個 function. 如果你能跑 gdb 的話, 只要問題發生時, 使用 bt (backtrace) 這個命令, 即可知道問題發生的地方在哪. 但是, 你所描述的這個問題, 只有 ARM 系列的 CPU 及 2.6.x 的 kernel 才會看得到. 通常在 embedded device 上, 要用 gdb 來 remote debug 也不是一件簡單的事. 在下提供一個方法, 可以不需要 gdb, 使程式發生問題時印出 backtrace 的 內容, 配合 addr2line 找出問題發生的地方(檔案,行數,function). 但在這 之前, 可以先試著使用 gcc 的檢查功能, 1. 編譯時, 增加 -Wcast-align -Wpadded -Wpacked 2. 修正所有編譯時出現的 Warning 如果程式碼不小, 那這可能會需要相當多的時間修正, 及重新編譯, 有些地方 也可能修了之後, 打壞了原本的架構, 而且, 這功能只能告訴你, "這樣的程 式碼, 有可能會發生這個問題", 不保證能指出真正發生問題的地方. 如果上述這個方法仍不能解決你的問題, 那麼, 後述的這個方法或許可以試試 看. (後面的內容十分冗長) [原理概述] 我們要在程式有問題的地方, 讓它中斷, 然後印出 backtrace 來讓 addr2line 反查. 因此, 我們分成以下三個步驟說明之. 1. 用 signal 讓程式在有問題的地方中斷 2. 印出 backtrace 3. 使用 addr2line 來解析其內容 [實作方法] 1. 用 signal 讓程式在有問題的地方中斷: 在 kernel 的文件 -- Documentation/arm/mem_align 裡有提到, 當有 memory alignment 的問題發生時, kernel 會做出一些處置, 像你所看 到的訊息, 即是 kernel 印出 warning, 這個行為是可以透過 /proc 變更的. 以下的指令可以檢視目前的設定, # cat /proc/cpu/alignment User: 0 System: 577 Skipped: 0 Half: 9076 Word: 4479 Multi: 0 User faults: 4 (signal) <----- 此為目前設定 關於 User faults, 有以下 5 種設定, 0 - ignore (預設值) 1 - warn 2 - fixup 3 - fixup+warn 4 - signal 5 - signal+warn (我們需要這個) 我們需要將行為模式設成 4 或 5, 理由是 4 和 5 都會在發生問題之時 送出 SIGBUS, 如果程式裡沒有 signal handler, process 就會被 kill 掉. 我們要利用這個 signal 來中斷有問題的地方, 並且印出 backtrace. 因此我們先更改模式為 5, # echo 5 > /proc/cpu/alignment 2. 印出 backtrace 這個部份, 需要利用 #include <execinfo.h> 裡的 backtrace(). 如果 source code 分成很多 .c 或 .cpp 的話, 請找出 main() 所在的那個 檔案來增加以下的 code, ----------------------------------------------------------------- #include <execinfo.h> #include <signal.h> #include <stdlib.h> /* 此為 signal handler */ static void catch_sig(int sig) { void *trace[128]; int n = backtrace(trace, sizeof(trace) / sizeof(trace[0])); backtrace_symbols_fd(trace, n, 1); exit(0); } /* 此函式指定 SIGBUS 的 handler 為 catch_sig() */ static void set_signals(void) { struct sigaction act; sigemptyset(&act.sa_mask); act.sa_flags = 0; act.sa_handler = catch_sig; sigaction(SIGBUS, &act, NULL); } /* 在你的 main() 的前頭, 呼叫 set_signals() */ int main() { set_signals(); : : } ------------------------------------------------------------------- 編譯時, 務必增加 -g -rdynamic 選項. 例: gcc -o prog -g -rdynamic prog.c 重新編譯及執行後, 若發生 Alignment trap, kernel 會送給這個 process 一個 SIGBUS 的 signal, 而我們在 set_signal() 裡, 設定了收到 SIGBUS 時要執行 catch_sig(), 而在 catch_sig() 裡, 我們利用 backtrace() 來 取得 stack frame 的位址之後, 用 backtrace_symbols_fd() 來印出比較 看得懂的資訊 (但還是得配合 addr2line 來解讀), 印出的內容看起來像是 以下這樣: # ./prog ./prog[0x8048743] --+---> 前面這兩行必指向 catch_sig(), 可以忽略 [0xffffe420] -------+ ./prog(func+0x1d)[0x804878c] --> 問題發生在這裡 ./prog(main+0xa3)[0x804883d] --> main() 呼叫了 func() /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7e21455] ./prog[0x8048691] 從這兒, 我們可以看到問題出現的地方在 func() 的 0x1d, 接下來, 下面 將介紹 addr2line 來更進一步解析問題出現的位置. 3. addr2line addr2line 的用法很簡單, 如下所示: 用法: addr2line -e 執行檔 -f 位址 承上例: # addr2line -e prog -f 0x804878c func ---------------------> 函式名稱 /home/haha/prog.c:312 ----> 檔案及行數 最後, 只要再注意一件事即可, 就是 312 這個行數, 還不是問題發生的正 確位置, 要如何取得確切的位置呢? 假設以下內容為 prog.c 的一部份, 309 void func() { 310 unsigned char *data = (unsigned char *)malloc(16); -> 311 struct st_bug *ptr = (struct st_bug *)data; * 312 printf("Hi, I am here\n"); : 387 } 我們發現到, 剛才 addr2line 解析出來的行數是 312, 但是問題其實不在 312, 而是 311, 那是因為呼叫 function 時, 要把返回的位址記錄在 Stack 裡的緣故, 因此當程式執行到有問題的 311 行時, process 會接到 kernel 送來的 SIGBUS, 然而, 在呼叫 signal handler -- catch_sig() 前, 因為 catch_sig() 執行完後, 要回到的位址就是 312, 所以會先把 312 的位址 先存在 Stack 裡, 再呼叫 catch_sig(), 而我們在 catch_sig() 裡呼叫 backtrace() 時, 它只是忠實的告訴我們每一個 function 被呼叫時, Stack 裡所預存的返回位址是什麼而已. (亦即每一個 stack frame 當時所紀錄的 位址). 因此, addr2line 看到的行數, 需要上移一行, 才是真正問題發生的 地方. (在此例也就是指 311 行) [此方法的其他應用] 利用"實作方法"的 2 和 3, 也可以用來捕捉 SIGSEGV (Segmentation Fault, 記憶體區段錯誤) 所發生的地方. 甚至是其他的 signal 發生時, 程式執行的位 置. [後記] 本來是睡不著, 才寫這篇, 結果, 寫完也不用睡了.... XD -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.171.78.159

12/02 07:51, , 1F
推 (Y)
12/02 07:51, 1F

12/02 09:28, , 2F
太強大了, 快推....<(_ _)>
12/02 09:28, 2F

12/02 09:53, , 3F
辛苦了
12/02 09:53, 3F

12/02 11:06, , 4F
超強!
12/02 11:06, 4F

12/02 14:42, , 5F
推~
12/02 14:42, 5F

12/03 21:39, , 6F
太感謝了, 明天馬上試試看!
12/03 21:39, 6F

12/06 23:09, , 7F
看到下一篇回來推同一系列的優文
12/06 23:09, 7F
文章代碼(AID): #1B5NrOv9 (C_and_CPP)
文章代碼(AID): #1B5NrOv9 (C_and_CPP)