RD = Redo & Debug

聽說 SS 社的 L 大作在 '05 狂 crash，銷售也不佳，後來 training 以及 code review 時機乎最重要的重點就是，注意 pointer。只要遇到 pointer 的情況，有 * or -> 就很容易被 focus。例如 function body 前面加入對 pointer 類型的 parameters 做 check，只要情況不對馬上謝絕掉。或許這招不錯用，至少可以馬上降低 crash 次數，畢竟幾乎所有的 invalid segment access 都可以避掉，立竿見影。至少這樣可以避免得到 crash comment 一枚，因為程式沒到該有的功能所以得到 bug functional。（註：只要列出來 call stack 就是 core dump，所以單純 return 沒做事至少不會出事）。 不過源頭呢？為什麼會有 invalid address 傳進去？當然就是程式有 bug，一定有地方出錯了，所以才讓那個 bug 一直存活下來，然後還傳遞給其他地方使用。現在好了，大家看情況不對，就盡量謝絕掉。那最後一定還是會出錯，只是出錯就會錯在無法避免的地方。可能最終的源頭跟最後出鎚地點相差十萬八千里，但是 AE/QA 就會看 call stack 或執行過哪些 commands 就把 bug submit 給誰。更慘的是，如果是遇到無法 reproduce 的 bugs，更是查不到來源，因為無法再重複一次，但是他就是曾經 core dump 出來給你看。最後只是 RD 猛去 disassemble 那個位址的 assembly code 來看，然後找相對應 source code 那邊是否有 pointer access 沒有保護好或有 bug。 再來是，大家一定遇過 core dump，最常見的就是 windows 的程式執行錯誤。或是 firefox 遇到 crash 也會有。Apple 也有 crash report 功能。裡面有什麼東西，大家一定看過，不外乎就是 call stack、thread list、module list、environment variables、registers、stack dump、memory dump。就連 unix-like 的環境，也可以產生一個 core file。最神奇的是 SS 社，雖然有 segment fault handler，雖然有 coredump file，但是其實裡面是 call stack 而已，連個 registers values、stack dump、memory dump 都沒有。如果是單純的筆誤 bug，很容易看一下相對應的 source code 就查到了。但是大型軟體下，又無法 reproduce，什麼都沒有 dump，只有 call stack function chain，查得到來源才有鬼。