[經驗]百思不解總算揪出來的bug

以往解bug的經驗，經常是有跡可循的，即使一開始不清楚原因，也大概知道要朝哪個方向調查，殊不知這次的問題異常的古怪，到客戶那折騰了一整天還弄不清楚。

事情是這樣的，我們公司的程式在客戶的電視牆上播放多媒體資訊，該程式已經是很成熟的產品，而且還有設置實體定時器，每天都會自動開關機，在這樣的狀況下，理應完美執行才對。不過客戶反映，早上開機後沒多久，就會在播放中突然凍結，重開機也一樣，雖不是每次都這樣，但發生機率很高，這就很怪了。

在這之前，就已發現那邊的網路環境在上班時間因為頻寬不足，會異常的緩慢，客戶每次派送的檔案都延遲很久或甚至沒播放，為了這個問題，還特地增加了續傳功能。沒想到還是一樣，看log後發現了很詭異的問題，檔案包內的特定json檔案下載不下來，但其他檔案都正常下載，見鬼了，找對方的資訊單位也沒用，事實擺在眼前，頻寬就是不足，改用我的手機分享Wifi就順了，為了這個問題業務也跟客戶盧很久，費了九牛二虎之力才說服是對方環境的問題。

但主要的凍結問題還是沒解，最蛋疼的是，凍結當下，連log都沒有，這下懵了，按常理產品很成熟，其他地方都正常執行，就不會是程式本身的問題，應該是環境因素造成的，果然測試後發現，換成手機Wifi時，就不會凍結。雖然可以重現，可是完全沒有關鍵的線索，無奈沒頭緒時，只好重頭開始，把流程的每一步思考一遍，是否有遺漏的地方。

我和業務就這樣在客戶大門口，不斷的測試，看log，甚至微調程式更新上去，都沒結果，最後卻突然靈光乍現！原來當初我為了避免程式的計時器延遲，一開始儲存了時間點，並在每秒執行時計算時間差，例如執行了1千次，理論上過了1千秒，但若時間差是1001秒，代表延遲了一秒，就需要補回來。就是這個設計，無意間隱藏了bug導致這個凍結的問題。

重新梳理一下過程，因為我們的播放盒沒有記憶時間，每次重開機時，時間會重置，從出廠時間開始，然後等到網路連通時，才進行時間同步。由於客戶網路環境緩慢，於是等到檔案開始播放一段時間了，才同步成功，此時因為前面說的時間差機制，出廠時間到當前時間的時間差秒數，根本是天文數字，等於讓系統跑了無窮迴圈，直接導致凍結，理所當然也就沒log輸出啦。至於解決方法很簡單，設定時間差上限就好了，像是超過5秒就無視，並且重新計算，就可以避免這個問題了。

發現真因的當下已經沒時間讓我完整的修改和測試，所以只能先關閉自動播放功能，會等到另一個背景計時到了才進入播放，因為時間較久，已經完成時間同步，待下次再來更新程式就好。這次經驗讓我了解到，添加每一個新的功能都需要考慮周全，也許當下沒發生，不代表未來不會發生，最後整到的還是自己啊~