??????? 先看看ASSERT的介紹：

?????? 編寫代碼時，我們總是會做出一些假設，ASSERT斷言就是用于在代碼中捕捉這些假設，可以將斷言看作是異常處理的一種高級形式。斷言表示為一些布爾表達式，程序員相信在程序中的某個特定點該表達式值為真。可以在任何時候啟用和禁用斷言驗證，因此可以在測試時啟用斷言，而在部署時禁用斷言。同樣，程序投入運行后，最終用戶在遇到問題時可以重新啟用斷言。

?????? 案例：

??????? 最近在跟一個客戶反饋的bug，客戶是做的安防家用云臺機監(jiān)控設備，說“設備掛測后異常，無法正常使用”的問題，也就是產(chǎn)品在老化的時候，本身應該是在APP端可以實時查看設備推流的視頻的，幸運的是客戶抓到了運行日志，以前客戶也老化過很長時間未出現(xiàn)過這種問題，當客戶把問題反饋到對外溝通群，公司甚是重視，立馬組織兵力調(diào)查，千萬不能耽誤客戶量產(chǎn)。

/*****************************************************************************************************/
聲明：本博內(nèi)容均由http://blog.csdn.net/edsam49原創(chuàng)，轉載請注明出處，謝謝！
/*****************************************************************************************************/

?????? 調(diào)查分析：

??????? 接到這個任務后，查閱了日志，日志足足抓了有三十MB，啟動大腦快速搜索蛛絲馬跡，終于看到一個比較明顯的錯誤，如下：

*********IDRFRAME_OVERFLOW ,frame_lost,len=86400************
[h264_vdi_enc_one_frame] H264_code_frame: overflow

?????? 也就是說編碼溢出了，在某些場景下，圖像噪點麻點太多，導致預設的編碼輸出buffer不夠存放編碼出這張圖的編碼后數(shù)據(jù)，導致overflow。還好提示夠明確，不然又不好復現(xiàn)真實要抓狂。找到H264 PictureBuffer.c: 535行看了一下，就是一個ASSERT處理，為啥會卡住呢？點開這個ASSERT的定義真是一目了然啊！如下

?? ? ? 兄弟啊，這ASSERT里面居然有個while(1)，真的要崩潰了，不就卡死在這里面嗎？

?????? 找到問題點后，找對應負責這個模塊的工程師同事溝通了一下，給我的建議是降低QP配置，也就是編碼質(zhì)量往下降一點，編出來的數(shù)據(jù)量會小一點，這當然也是一個有效手段。但是我覺得這還是一個問題，變成一個更加難復現(xiàn)的問題，從本質(zhì)上、原理上還是存在再進入這個ASSERT在這里執(zhí)行while(1)的可能性，概率雖然會降低，但是出現(xiàn)了它的后果是相當于死機的TOP0級別了,不容忽視吧!

????? 談了一下我的想法,這種硬件視頻編碼器如果數(shù)據(jù)大了不夠存,大不了就不要這個數(shù)據(jù)了嘛,這一幀編碼失敗返回就行了, 頂多影響一個GOP的數(shù)據(jù)吧，這頂天了！你如果一直在while(1）不就是等同死機了嗎？因此我建議去掉while(1)處理，有錯了就返回重新再出發(fā)，不必卡死在那。

???? 心得體會：

????? 有些錯誤我們是可以預估到，但是沒法完全避免，首先我們要有防錯的思維，就像我那同事提出的降低編碼等級，數(shù)據(jù)量小了，也是一個有效手段，但是不能以防萬一，不能根治；其次，在防錯的基礎防線上沒守住的時候，我們還得有糾錯的思路，讓損失降低到最小吧！

???? 軟件編程防錯和糾錯都必不可少，多一些質(zhì)量管理的思維，考慮全面一點，程序也就更健壯一些。

?????