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

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

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

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

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

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

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

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

發表迴響

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

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

Create a website or blog at WordPress.com

向上 ↑

%d 位部落客按了讚: