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

?????? 編寫代碼時(shí)，我們總是會(huì)做出一些假設(shè)，ASSERT斷言就是用于在代碼中捕捉這些假設(shè)，可以將斷言看作是異常處理的一種高級(jí)形式。斷言表示為一些布爾表達(dá)式，程序員相信在程序中的某個(gè)特定點(diǎn)該表達(dá)式值為真?？梢栽谌魏螘r(shí)候啟用和禁用斷言驗(yàn)證，因此可以在測(cè)試時(shí)啟用斷言，而在部署時(shí)禁用斷言。同樣，程序投入運(yùn)行后，最終用戶在遇到問(wèn)題時(shí)可以重新啟用斷言。

?????? 案例：

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

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

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

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

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

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

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

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

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

???? 心得體會(huì)：

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

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

?????