先看看ASSERT的介绍：
编写代码时，我们总是会做出一些假设，ASSERT断言就是用于在代码中捕捉这些假设，可以将断言看作是异常处理的一种高级形式。断言表示为一些布尔表达式，程序员相信在程序中的某个特定点该表达式值为真。可以在任何时候启用和禁用断言验证，因此可以在测试时启用断言，而在部署时禁用断言。同样，程序投入运行后，最终用户在遇到问题时可以重新启用断言。
案例：
最近在跟一个客户反馈的bug，客户是做的安防家用云台机监控设备，说“设备挂测后异常，无法正常使用”的问题，也就是产品在老化的时候，本身应该是在APP端可以实时查看设备推流的视频的，幸运的是客户抓到了运行日志，以前客户也老化过很长时间未出现过这种问题，当客户把问题反馈到对外沟通群，公司甚是重视，立马组织兵力调查，千万不能耽误客户量产。
/*****************************************************************************************************/
声明：本博内容均由http://blog.csdn.net/edsam49原创，转载请注明出处，谢谢！
/*****************************************************************************************************/
调查分析：
接到这个任务后，查阅了日志，日志足足抓了有三十MB，启动大脑快速搜索蛛丝马迹，终于看到一个比较明显的错误，如下：
*********IDRFRAME_OVERFLOW ,frame_lost,len=86400************
[h264_vdi_enc_one_frame] H264_code_frame: overflow
也就是说编码溢出了，在某些场景下，图像噪点麻点太多，导致预设的编码输出buffer不够存放编码出这张图的编码后数据，导致overflow。还好提示够明确，不然又不好复现真实要抓狂。找到H264 PictureBuffer.c: 535行看了一下，就是一个ASSERT处理，为啥会卡住呢？点开这个ASSERT的定义真是一目了然啊！如下
兄弟啊，这ASSERT里面居然有个while(1)，真的要崩溃了，不就卡死在这里面吗？
找到问题点后，找对应负责这个模块的工程师同事沟通了一下，给我的建议是降低QP配置，也就是编码质量往下降一点，编出来的数据量会小一点，这当然也是一个有效手段。但是我觉得这还是一个问题，变成一个更加难复现的问题，从本质上、原理上还是存在再进入这个ASSERT在这里执行while(1)的可能性，概率虽然会降低，但是出现了它的后果是相当于死机的TOP0级别了,不容忽视吧!
谈了一下我的想法,这种硬件视频编码器如果数据大了不够存,大不了就不要这个数据了嘛,这一帧编码失败返回就行了, 顶多影响一个GOP的数据吧，这顶天了！你如果一直在while(1）不就是等同死机了吗？因此我建议去掉while(1)处理，有错了就返回重新再出发，不必卡死在那。
心得体会：
有些错误我们是可以预估到，但是没法完全避免，首先我们要有防错的思维，就像我那同事提出的降低编码等级，数据量小了，也是一个有效手段，但是不能以防万一，不能根治；其次，在防错的基础防线上没守住的时候，我们还得有纠错的思路，让损失降低到最小吧！
软件编程防错和纠错都必不可少，多一些质量管理的思维，考虑全面一点，程序也就更健壮一些。
