2013年10月2日 星期三

When in doubt, disassemble.

先寫結論:

  1. 要在不疑之處有疑
  2. 苦無對策的時候,disassembler有機會幫上忙
今天一上班,看到daily regression crash一大片,想說挑個小的case來解解看。

Local build跑下去,沒事,GDB完全不想停。
Daily build跑下去,crash,但是只知道function name,不知道在哪。Call stack列出來的那幾個function昨天都沒有動過。
跑Valgrind,沒有任何發現,能跑的還是能跑,會crash的還是crash。
換台機器,一樣是daily build crash,local build沒事。
其他同事各自使用local build,沒事。
其他platform,通通都沒事。
請求重建daily build,不被接受,因為daily build真的會crash,實在難以證明重建daily build是正解。
好啦,沒招了,只好按兵不動,對於所有人的詢問一律答以「明天應該就沒問題了」,心裡還想萬一明天狀況一模一樣就要倒大楣了。

數十分鐘後...
靈機一動,不如來看看daily build executable的那支function到底長成什麼德行。

(gdb) disassemble my_function

上下看一看,怎麼會出現連續十幾個完全一模一樣的add instruction?而且還出現了好多次?這支function還蠻複雜的,直覺覺得不該出現太trivial的行為。
已知這支function昨天完全沒動過,拿出更早一天的daily build,同樣實施disassemble。連續的add instructions不見了。顯然是compile的時候錯了。

把兩次disassemble的結果當作呈堂證供,再次請求重建daily build。收到回答,重建一個source file就一切正常了。

至於到底為什麼會只有這麼一個檔案有問題?只有這支function有問題嗎?
不曉得,不予追究,就假設是在那一瞬間RAM cell被alpha粒子打中吧。