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 工具真不知道怎麼追.

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s