2023年8月1日,周四下午,專案經理突然告訴我說:之前能用的車輛控制介面現在都報錯了,車輛上傳的日誌解析也全都解析失敗!
看到這裡,我認為應該是車機系統做了公升級,導致和之前的報文產生規則有了差異,導致解析出錯,不過控制命令的報錯應該是另一回事.
因為報文解析出錯比較好解決,本地模擬線上環境,開debug,進斷點,發現是16進製制轉2進製的時候需要補齊8位,我之前的**是用迴圈的方法,迴圈判斷長度是否<=8,《則在字串前+0;但是當時由於經驗(現在看來當然是失敗的經驗),我選擇每次都迴圈5次,而不是迴圈8次.當時選擇這麼做有兩個原因,乙個是根據當時跟我對車輛回傳資料的"經驗"判斷,16進製制轉2進製字串以後最少有3位長度,2是因為每次都迴圈8次太浪費資源(事實證明想節省資源有更好的方法).所以我就每次都做了5次迴圈.
debug到這裡時,發現是補0沒有補全的問題,就把這裡的i<5,改為i<8;然後測試了一下,哎,問題解決了
然後又順便測試了一下車輛控制介面的問題,咦,竟然也神奇的解決了.
解決了就好,雖然不知道咋回事,但是畢竟問題已經解決了.
但是因為這專案已經是馬上要正式上線了,專案經理要求一定要搞清楚問題是什麼原因導致的.
我的天啊.
開始了漫長的問題回溯.
首先可以確定的是,報文解析出問題是由於報文變化了導致的,雖然是補零可以解決這個問題,但是之前的報文解析<=5就可以正常解析,為什麼到今天就不好使了呢,我直接現在都以為是報文的問題.
經過漫長的debug,終於有所發現
這裡先貼一下我這個報文的日期解析的規則
之前7月的時候,由於數字1-7進行10進製轉2進製字串後長度都為3位及以下,舉例,7十進位制轉2進製為111,我的報文拼接規則為,月份欄位佔4位,分別在上乙個2進製串的7~8位和下乙個串的1~2位,然後進行拼接,比如7月份的話,就是01+11拼接起來為0111
但是到了8月的時候,就變成了10~00,然後日期佔3~7位,1號,二進位制也為1,該轉換完成以後的字串就變成了0000001x
舉例說明,後面的x是小時的第一位
在這種情況下,我之前迴圈5次判斷以後,然後在前面補0的操作以後,0000001x就變成了000001x
然後在小時字段需要取當前字串最後一位也就是第8位的時候,發現當前字串只有7位,ok,空指標異常,接下來的事情大家應該就都知道了...
整件事情回想起來,就是因為之前的大量報文測試工作中,盲目自信的認為已經找到了規律,可以通過減少判斷的方法提高效率,從而導致了如此尷尬的bug...
記一次慘痛的除錯經歷
背景 在處理乙個重新命名操作時，需要將檔案以指定的名稱存到指定的目錄下，同時將原目錄下的相關檔案全部刪除 問題 能夠將原始檔重新命名，分片mp4的形式能夠將整個目錄刪除，但以整段mp4刪除時，始終無法刪除對應的.property檔案 解決經歷 1.在xcode下模擬，始終是不會出現任務刪除不掉問題 ...
記一次npm的奇怪bug
近幾天npm不知怎麼了不能安裝包了，連cnpm都不能安裝了，於是開始開 ku 心 bi 的除錯。網上的方法基本上全都試過了，結果出現了這個東西 這是讓我刮獎嗎？google一下，還真有這樣的錯誤，好像是埠被占用了。好嗎，三下五除二改下埠，發現還是不行。仔細觀察發現網上貼出來的錯誤跟我的錯誤還不一樣，...
記一次尷尬的git reset丟失分支故障
最近.似乎一直在踩坑.也不是什麼故障,只是把乙個分支的功能弄沒了,之後在reflog裡找到又恢復了.產生原因是有同事錯誤地把分支b merge到了分支a並push.我直接在分支a上reset到了merge前的乙個節點 但這個節點其實是b分支的 這導致分支a的頭跑到了b分支上,a本來那個分支沒有引用就...