一個歷時五天的 Bug

  • 2019 年 10 月 6 日
  • 筆記

一個程式設計師在沒有成長成為架構師之前,幾乎都要跟 Bug為伴,程式設計師有很多時間都是花在了查找各種 Bug上。

我印象深刻的一個Bug, 是一個伺服器網路框架無鎖隊列的 Bug 。那個 Bug 連續查找了五天的時間,才最後定位出來。

當時我們的分散式存儲系統出現了性能瓶頸,定位後發現瓶頸是在伺服器網路框架上,所以我們決定為此替換一個最新研發的網路框架。這個新的網路框架為了追求高的性能,採用了無鎖隊列的設計。

第一天編碼測試完成後。測試環境跑,完全正常,特地搞了一堆 log 來重放請求,程式跑得特別歡快。解決了當時的性能瓶頸,感覺特別的開心,但好景不長,服務部署到現網環境,跑不到一個小時,就 coredump 了。

嘗試上線了幾次,每次都是跑半個多小時,就 coredump 。

當時的第一反應是新網路框架的問題,這是很直覺的反應,但很快就產生了懷疑,因為這個框架也有其它模組在用,也沒產生問題,當時覺得詭異了。

仔細查看了程式碼的修改記錄,特定檢查了版本管理系統的 log, 做了程式碼 diff, 確定確實只有這部分的修改。憑著經驗,我說服自己,這個時候應該堅信最明確的邏輯,不要走到其他歪路上去。

第二天,我把這個框架單獨拎了出來,特地寫了一個測試的模組,並用測試程式碼生成了一堆的請求數據,發送給測試模組。它瘋狂的運轉起來,跑了一個多小時,跑得很歡快,一切正常,啥 Bug 都沒有。

開大了並發,繼續壓,依然沒有問題。懵逼了!不知咋回事。再次小心得灰度系統上線,跑不到一個小時還是 coredump 了, 這個時候,我開始懷疑人生了,這個是咋回事了,都想砸鍵盤了都。

然後我冷靜了下來,經驗告訴我,這時應該按照正常流程完整地跑一遍測試模組。於是我把那個測試模組打包成了現網模組,切走了一台現網機器的流量,把測試模組給上線到了一台現網機器。

之後用工具往現網機器發送數據,不到一個小時,coredump 了。終於復現了這個 cordedump, 那一刻猶如哥倫布發現了新大陸,簡直欣喜若狂啊。這個時候已經是第三天了。

我復現了 Bug,但依然沒辦法定位出具體的原因。coredump 出來的棧是全亂的,沒有任何價值,接下來,就開始用 log 跟蹤法了。

我依據數據的流轉過程,在每個關鍵點,都打上 log,log 包含了所在的函數,行數,程式邏輯的編號,全部的關鍵數據等等。我仔細地設計了這個log,爭取打得不多不少,太多容易看暈頭,而且太多無效的資訊,會掩蓋了真正的問題;太少,資訊不足,又不足以判斷,所以這種情況下打 log 也是個藝術活。

通過精心設計的 log, 終於發現數據在一個特定的環節混亂後,程式就一定會 coredump。分析log , 發現數據包在最後時刻是完整的,但包似乎出現了亂序和重複。這個時候,才開始意識到可能是無鎖隊列的問題,因為只有隊列出問題,包的進出順序才會亂掉。

然後又花了半天的時間,專門為無鎖隊列寫了測試用例,用數據瘋狂地懟。在測試環境,依然一切安好,但上線到正式環境,壓測半小後,終於掛了。終於看到了勝利的曙光!這個時候已經是第四天了!

到現在已經很明確是無鎖隊列的問題了。但這個數據結構的程式碼不到 200行。我拉了兩個同事一起 review,都沒發現問題。但就是 coredump 了。

奇葩了,又陷入了人生懷疑,開始懷疑記憶體,懷疑 cpu,結果換了機器,還是一樣。

後來,仔細地對比了現網環境和測試環境的區別,機器類型,作業系統版本都一樣。然後編譯器?咦!編譯器?上去看了一下,結果發現編譯器的版本不一樣!這段時間我所使用的現網編譯環境升級了新的 gcc 版本,但測試編譯環境,還是舊的版本的。(這個也比較坑)

當時的直覺是肯定跟編譯器相關,但程式碼都一樣,難道是編譯器bug?不可能吧 ?! 後來想,不如將它們轉換成彙編看看吧。於是用兩個版本的編譯器將C的程式碼各自轉換成了彙編。然後diff 彙編程式碼,哇!發現真的有一行是不同的!

後來自己分析對比,發現是因為我們開啟了gcc最高級別的程式碼性能優化,不同版本的 gcc 在一些沒有特定依賴的語句上的優化是不同的。

說人話,就是有一段程式碼,如果加了鎖,兩個版本的編譯器下,都會產生一樣的彙編,如果沒有加鎖,程式碼有一行的順序被調整了,當然,從編譯器優化的角度講是對的,是我們使用姿勢不對。

但無論怎麼樣,終於找出了這個問題。蒼天啊! 找了五天呀! 最後當然是開開心心地上線了。

查這個bug 確實花費了很多的時間,不過也是沒辦法,你不解決bug,就不能上線,但中間也收穫不少,特別是對編譯器優化有了很深的印象,也算是為自己的查 Bug 能力,又貢獻了一波經驗吧。

對於 Bug , 我分享下自己的一些認識和建議。

面對 Bug 的態度

只要你持續地寫程式碼,就一定會持續的產生 Bug,所以第一個事情是要擺正對 Bug 的心態。我遇到過兩個極端。

第一個極端。

遇到過一個leader,對系統品質相當重視,對我們寫的程式碼要求很高,每次設計並寫完一個新的系統,他喜歡跟你算這次的系統上線,產生了多少次故障,這半年時間產生了多少個 Bug,每個 Bug 的影響範圍如何。

我們一堆人被搞得特別累,戰戰兢兢,到後面,大家都比較排斥去做優化,去重構程式碼,只求無過,不求有功了。所以,我覺得這種方式不好,對 Bug 帶著一種比較包容的態度去看待,可以減少不少的心理負擔。

第二個極端。

後來去了一個新的團隊。新的團隊很重視業務和工程迭代的速度,所以對程式碼品質和 Bug 的容忍度很高。如果是一個新上線的業務,是默許 Bug 存在的。

這種對品質過於鬆散的要求,在後面也帶來不好的影響。大家對 Bug 太免疫了,以至於出現 Bug 和 故障的時候,大家都不夠緊張。系統品質有一段時間出現比較大的問題,還因此被部門經理特訓了一番,後面通過各種措施,才慢慢提高了整體的系統品質。

上面兩種極端都不可取,應該很重視 Bug,盡量避免 Bug,但也不應該唯 Bug 多少論業績。

具體到 Bug 的查找上,我說說我的一些經驗。

Bug 的復現

我把 Bug 分為可重現的 Bug 和不可復現的 Bug 。

對於可重現的 Bug , 查找起來比較容易,比如可以用」二分查找「的方式,從模組層面開始定位起,每次折半,每次折半地縮小範圍,一直到程式碼層面。

在程式碼層面,遵循一些常用的原則:比如看到記憶體拷貝,直覺上要想到記憶體越界;看到數組,就要考慮是否索引越界;看到指針,就要考慮是否正確解構;看到多執行緒,就要考慮是否執行緒安全;

對於不可重現的 Bug , 第一步就是要把它重現出來。有時候特別的難,特別是並發形態下產生的 Bug ,出現的時機和觸發條件都不清楚。對於這種 Bug ,只能通過各種嘗試去復現它。

比如將多並發調整為單並發的方式,看能否復現,如果可以復現,就可以轉化為可復現的 Bug ,用」二分查找「的方式去排查。

如果不能復現,那極大概率是並發問題。這個時候最好先停止排查,仔細分析程式在並髮狀態下可能出問題的點。大部分並發問題的根源,是互斥數據沒有被正確讀寫,或者一些共享狀態被錯誤修改。

靜態程式碼檢查

利用coverity等程式碼檢查工具進行程式碼的靜態檢查可以發現很多潛在的問題,而且修復的成本很低。團隊後來引入了這個檢查工具,確實帶來了不錯的效果。類似變數未初始化,疑似的記憶體越界等都有可能被檢查出來。

編譯器的 warning。有些同學一開始的時候對 warning 不重視。我們團隊早期也遇到過這個情況。

那時候產品迭代的速度很快,所以大家寫完程式碼,能夠編譯通過,就進行各種測試,然後準備上線了。一開始的一兩個warning, 不太理會。後面發現越積越多,到最後終於成為一個不得不解決的問題。

部門還為此特地立項,來消除warning。先是在內部多次強調了這個理念,然後從基礎庫,基礎模組開始實施,基礎程式碼部分統一 fix warning, 然後開啟編譯器把 warning 當 error 的開關。完成之後,再逐步地推業務模組進行修改。反正折騰了好一段時間。

工欲善其事必先利其器

程式碼 Bug 出現的時候,善用一些排查工具可以極大得提升效率。比如對於C/C++ 的 gdb 調試,記憶體泄漏時候 valgrind 的檢測,linux 下面用 perf top 來析 cpu 的消耗等。

一開始的時候,我對這些工具不重視,老是覺得真正使用的時候,去查文檔就行。後面才發現,用工具查著問題時候,遇到不會用的命令或功能,再去查文檔,是個痛苦的事情,來回切換的開銷也使得效率低下。

後面就對這些輔助工具的使用重視了起來。,專門花時間去學習和練習使用,反而提升了不少的效率

打 log 的藝術

很多時候,出現一個 Bug,未能定位出來,需要打上更多額外的 log 來輔助排查。一開始的時候,是想到一點,打一個 log,後面發現這麼做沒有章法,邏輯不清晰, 排查效率低下。

後來學會了,遇到 Bug 後,先在腦子裡面分析一番,然後花一兩個小時詳細地設計 log 的格式和打 log 的位置。發現這種方式對查問題的效率提升很大。

所以遇到 Bug 的時候不要急躁,先靜下來心來分析,在腦海里儘力重現出完整的運行邏輯,然後仔細地進行 log 設計,包括 log 包含的欄位,打 log 的點等。這樣能極大的提升排查問題的效率。

結語

Bug 是程式設計師最不願意用面對,但又經常出現的一個 「詭異生物「。對待Bug 要有正確的心態,最好不要跟業績強綁定,也不能太過於疏忽。Bug 的排查是個很複雜的事情,每個人都有自己的方式和做法,如果你有好的做法和建議,也歡迎在留言區分享給大家!