嵌入式内存泄漏造成死机的问题如何管控

Posted 2022-01-28 太阳德生

      传统的我们提高软件代码管理质量，我们有编码规范，代码人工审核，测试等手段来监控软件开发成果，在紧张的开发节奏中往往容易走形，各种不规范和不如人意的代码经常出现，给开发产品的整个质量造成非常大的影响。笔者最近就遇到一个原厂SDK里的bug，把人整的晕头转向。

      事情是这样的，在开发的产品测试中，规律性的测到机器跑机会死机，进一步多几台测试，发现部分死部分不死，再分析差异，得出死掉的机器都是没有正常写入机器条码。得到这一条线索也是费了很大劲。接到这个状况后，立马着手调查。出错的机器打印是这样的：

[2021/11/30 21:02:55] [A.APP  ][000057.835074][  41C]
[2021/11/30 21:02:55] [A.APP  ][000057.838682][  34C]FILE: fwmgr/rkpart.c, LINE: 207: vendor_storage_read fail
[2021/11/30 21:03:00] [A.APP  ][000057.845061][  41C][Vendor ERROR]:No matching item, id=1
[2021/11/30 21:03:00] [A.APP  ][000062.605210][  39C]
[2021/11/30 21:03:00] [A.APP  ][000062.608720][  34C]FILE: fwmgr/rkpart.c, LINE: 207: vendor_storage_read fail
[2021/11/30 21:03:00] [A.APP  ][000062.615103][  39C][Vendor ERROR]:No matching item, id=6
[2021/11/30 21:03:00] [A.APP  ][000062.624877][  34C]
[2021/11/30 21:03:00] [A.APP  ][000062.628505][  34C]FILE: fwmgr/rkpart.c, LINE: 207: vendor_storage_read fail
[2021/11/30 21:03:04] [A.APP  ][000062.634883][  35C][Vendor ERROR]:No matching item, id=1

     是没有匹配到id为1的item，首先就先模拟出环境，就把有条码的机器把条码擦掉，这样还是没有复现出来，这个就奇怪了，同样是没条码为什么出错不一样，不得不查看更深的源代码。。

[2021/11/30 22:25:10] [A.openc][000000.296008][   0C]
[2021/11/30 22:25:10] [A.openc][000000.298706][   0C]FILE: fwmgr/rkpart.c, LINE: 212: vendor read Type 12 :0¤
[2021/11/30 22:25:10] [A.openc][000000.304213][   0C]
[2021/11/30 22:25:10] [A.openc][000000.309585][   0C][LOG][DeviceWifiInit][155]#######*********###DeviceWifiInit ServerId rret=127, tmp_buf= 0¤,val: 0
[2021/11/30 22:25:10] [A.openc][000000.320434][   0C][Vendor INFO]:Find the matching item, id=1
[2021/11/30 22:25:10] [A.openc][000000.327579][   0C]
[2021/11/30 22:25:10] [A.openc][000000.349500][   0C]FILE: fwmgr/rkpart.c, LINE: 238: vendor write 1 :
[2021/11/30 22:25:10] [A.openc][000000.354865][   0C]###DEV_SN: wRet:0
[2

   

int vendor_storage_read(uint32 id, void *pbuf, uint32 size)

    int ret = 0;
    uint32 i;
    uint16 offset;
    struct vendor_item *item;

    /* init vendor storage */
    if (!vendor_info_init)
    
        ret = vendor_storage_init();
        if (ret < 0)
            return ret;
    

    item = vendor_info.item;
    for (i = 0; i < vendor_info.hdr->item_num; i++)
    
        if ((item + i)->id == id)
        
            /* PRINT_E("[Vendor INFO]:Find the matching item, id=%d\\n", id); */
            /* Correct the size value */
            if (size > (item + i)->size)
                size = (item + i)->size - 1;
            offset = (item + i)->offset;
            memcpy(pbuf, (vendor_info.data + offset), size);
            return size;
        
    
    printf("[Vendor ERROR]:No matching item, id=%d\\n", id);

    return (-1);

   猛然发现一个巨大的坑，内存泄漏了。

COMMON API int get_device_pnc(dev_sn_type_t dev_sn_type, char *strBuf, int len)

    int ret;
    if (!strBuf)
        return -1;
    memset(strBuf, 0, len);

    ret = vendor_storage_init();
    if (ret < 0)
    
        DEBUG("vendor_storage_init fail \\n");
        return  -1;
    

    ret =  vendor_storage_read(dev_sn_type, strBuf, len);
    if (ret < 0)
    
        DEBUG("vendor_storage_read fail \\n");
        return  -1;
    

    rk_printf("\\n");
    DEBUG("vendor read Type %d :%s \\n", (int)dev_sn_type, strBuf);

    vendor_storage_deinit();
    return ret;

    在vendor_storage_read（）失败的情况下，会直接退出，而在初始化的时候有动态申请内存，如下：

       所以在裸机器里没写过SN的设备上，每次去读，读不到就会造成一次泄漏。由于这个sn在产品功能上有很大作用，因此应用也是没读到的情况下会去尝试很多次，以至于内存耗尽，油干灯熄了。这样一个大死机问题就找出来了，解决办法就很简单了，在return返回之前把内存释放掉即可。往往疑难杂症的bug的最后都是很简单的问题造成的，难就难在分析的过程，思维能力的锻炼，找到突破口。有点像福尔摩斯破案一样，找软件bug就是破软件的案。

     那怎么提高这种代码的管理质量呢？

1、有一个好的，达成共识的编码规范；

2、增加人工review代码的流程，了解设计者的逻辑；

3、测试用力覆盖面增加，尽量不留死角；

4、加强培训，提高编码能力，降低埋bug可能性；

5、引入自动化工具，比如sonar，功能强大，真的挺不错的。

Sonar是一个用于代码质量管理的开源平台，用于管理源代码的质量，可以从七个维度检测代码质量。通过插件形式，可以支持包括java,C#,C/C++,PL/SQL,Cobol,JavaScrip,Groovy等等二十几种编程语言的代码质量管理与检测。

 

 哪里有可疑问题，内存泄漏问题都能帮你扫描出来！真的太棒了！