按月存檔：十二月 2005

Shared Library v.s. Segmentaion Fault

留言

最近碰到的 bug, 背景說明

Program A
Library C, Library C 會 dlopen() C1.so 進來跑
Library S, Library C 會 dlopen() S1.so 進來跑, S1 會 用到 Library U 的 function
呼叫順序是 A -> C -> C1 -> S -> S1
因為會 core dump, 所以把呼叫 S 的 funtion 拿出來做成 unit test program, 跑個幾百次都沒事.

core dump 以後用 source debugger 看不到當在那一行，只看到 segnetation fault 的 signal 被 Main Thread 接到

懷疑是 C 或 S 亂寫 memory 把對方寫爛了，拿出 glib mcheck 檢查，檢查不出甚麼東西

拿 出 valgrind, 同事把在 S/S1 裡出現的 memory leak 都修完了, 還是一樣 core dump. 而且似忽都是跟著 C 裡面某個定期的事件出現，沒辦法了, 請 C 的作者給我們一個 debug build. 一起來確認到底是 C 還是 S 還是 U 的問題.

晚 上十一點多，另一個同事也會在 call 到 S 以後 core dump，同時發現固定的呼叫 30 秒以後當掉，兇手鎖定到 S，老闆開始追查，原來是S1 裡面用了 alarm(), 但是在結束前沒有清掉，結果因為 signal 發生時 signal handler 已經 unload 掉不在 memory 了, 就 coredump 順便一路丟回到 main thread.

為甚麼我在查的時後總是跟著 C 裡面某個事件一起出現呢? 因為正好也是 30 秒, orz.

要不是因為 S 的 source 在手上，沒有可以一路貫通 program/shared library/system call 的 debug 工具真不知道怎麼追.