最具殺傷力的小BUG @ 牛奶生活日記

　　軟體界有句俗語：『吃燒餅哪有不掉芝麻的，寫程式哪有沒BUG。』BUG之於程式設計師，由如影之隨形，亦步亦趨，卻不易察覺。

　　當系統開發工作在晨曦中緩緩展開之時，它就悄悄地潛伏在你身邊。當開發工作如火如荼地進行，聲勢如日中天之時，它就在你的腳下，但是你卻老是刻意忘記它的存在。直到開發工作接近尾聲，夜深人靜之時，它卻化身為幢幢黑影，張牙舞爪的圍繞著你，侵蝕著你，你伸手抵抗，卻發現對它毫無還擊之力。

　　BUG是程式設計師揮之不去的夢魘，人人無不對BUG恨之入骨，欲除之而後快，卻往往不得其法。

　　要『生』一個BUG很簡單，但要把BUG從一個複雜的系統中『挑出來』，就沒有那麼容易了。根據經驗，往往只需要一個很小的BUG，就可以把一群『精英』搞得人仰馬翻，求生不得，求死不能。

　　我遇過最具殺傷力的小BUG，真的只是一個小小小小BUG而已唷，就讓一批賦有經驗的精英團隊死在裡頭：從一開始在產品發表會中一鳴驚人，獲得眾人關注，卻因這個小瑕疵而無法打開市場，直到產品的生命週期終結，面臨淘汰的壓力時，才終於把BUG解掉，但時空環境已經改變，終究無法反攻已經消失了的市場。

　　我當初之所以『有幸』接觸到這個案子，是在前述的精英團隊在與此BUG奮鬥了兩年之後，因為人事更迭，團隊解散，因緣際會下由我們接手『擦屁股』。在一開始，我們就發現了幾件事情：

1. 對方精英團隊確實並非泛泛之輩，竟然無法解決此BUG。

2. 種種跡象都將問題矛頭指向儲存動作不穩定，但就是不知道是硬體問題還是軟體問題，亦不知道是檔案系統問題，還是flash driver的問題。

3. 相關的程式碼，從檔案系統到flash driver，都已加上大量的容錯機制，而且還開啟了flash硬體模組的bad block機制，還規額外劃出一塊flash空間，以軟體的方式來加強flash對bad block的處理。

4. 此BUG發生的機率微乎其微，可能跑上一個禮拜只會遇到一次有問題的狀況，這是這個BUG最令人頭大的地方。

　　以上各點在在都顯示了，這個案子是『賽』中的『大爛賽』，最好是不碰為妙，一旦沾上了，一世英名可能會變成臭名，因為有『賽味』啊！

　　非常幸運的，我們很快的發現了檔案系統並不是此BUG的主因，接著又發現在Linux執行之前的boot loader時期，flash的讀寫動作是正常的，但是Linux跑起來之後，檔案的讀寫，也就是flash的讀寫，就開始發生問題了。因此，我們將重點火力鎖定在flash driver上。

　　我們一反過去不斷加強容錯機制的策略，將焦點鎖定在不可能會出錯的硬體動作上，把flash的datasheet翻出來，一步一步對照flash driver中的每一個硬體動作，找出和datasheet不合的動作或動作順序。

　　這其實有些困難，因為Linux結構化風格的程式碼，把一連串的硬體動作拆散到好幾個地方，必須在腦中把這些四分五裂的程式碼，小心翼翼的組合回來，才知道flash底層到底做了什麼事。而Linux多工的特性，必須將程序切換的所有可能性做排列組合，才能找到有問題動作順序的組合。

　　或許你會問，為什麼不多印些訊息啊，因為此BUG發生的機率微乎其微，印得越多，垃圾訊息就越多。況且印訊息要經由com port，這是Linux中的另一隻driver啊！Linux多工的特性會使得一隻driver的動作影響到另一隻driver的硬體延遲時間，硬體延遲的時間變了，結果也會不一樣唷！而實際上多印一些訊息，的確會讓BUG出現的機率又更低了。天呀！守株待兔的我，希望BUG早一點出現啦！

　　再經過一段時間之後，還真的被我找到了一個硬體動作的錯誤，這著實令我意外，因為這是Linux原生的程式碼，在多年中經過了許許多多的程式高手的檢驗，居然都沒人發現這裡有問題。而修正這個錯誤僅僅只改了一個數字：5改成4。

　　說實在的，由於此BUG發生的機率微乎其微，可能跑上一個禮拜只會遇到一次有問題的狀況，即使跑了兩週都沒問題，也無法完全確認此BUG是否真的被修正了。因此我們繼續找問題修問題，但再也找不到其他令人振奮的問題點了。

　　在幾個月之後，在官方以多台機器同時執行，反覆的驗證之後，終於確認問題已解決，真的只是一個數字造成的BUG。所有繁複的、沒效率的容錯機制，統統都可以脫掉。我心頭的負擔，也跟著一併脫掉了！

　　兩年多這個BUG來殺掉了多少位英雄豪傑呢？這真的是殺傷力最大的小BUG啊！

　　印象中笑傲江湖裡似乎有這麼一句名言：