阿里网站,重庆游戏公司,知识付费分销平台有哪些,网络运营者不是指维测典型案例分析1 —— 内存泄漏
在系统运行的过程中#xff0c;内存泄漏是较为常见但是很难复现的现象#xff0c;一般的内存泄漏点都是比较隐蔽的#xff0c;每次几十个字节的泄漏#xff0c;往往需要压测很久才能复现问题。本节案例分析#xff0c;我们从一个已经压测…维测典型案例分析1 —— 内存泄漏
在系统运行的过程中内存泄漏是较为常见但是很难复现的现象一般的内存泄漏点都是比较隐蔽的每次几十个字节的泄漏往往需要压测很久才能复现问题。本节案例分析我们从一个已经压测出来的问题出发通过维测工具的使用来看一次内存泄漏的分析。 1. 问题现象
xx平台压测反复断AP电源第488次连接通道时出现dump机现象 **
2. 重现步骤
设备认证连接并保持在线状态维持心跳 b. .待连接稳定后断开网络断AP电源 c .5分钟后恢复AP电源 d .查看设备端日志判断设备是否上线3. 问题初步分析
从压测过程看是设备和路由器循环断开重连的操作没有连云也没有起业务。这部分仅仅是调用厂商的wifi 驱动库。 从问题出现的log来看发生了系统crash并且出现了典型了内存不足的打印如下 这个Log是我们维测体系中的设备端能力之一将发生内存出错时候的内存使用情况全部输出方便定位 这是由于内存不足无法从系统内存池中mallo出动态内存出现这种现象一般有2种原因
某组件在运行中持续分配了较大内存并且一直还没释放。这种情况可能性不大内存泄漏了根据压测描述压测了几天才出现发生了缓慢泄漏。
初步分析到此我们先用PC端维测工具对这个设备端log解析一把看看有什么有价值的信息出现。维测工具的使用参加另一篇文章介绍。这里直接使用
python core_dump.py log xx.elf
维测工具输出了对设备端log的解析打印出了上图中内存泄漏时的系统内存使用情况的一次统计如下图 这里对系统crash时所有动态内存分配情况进行了统计按照内存分配size 从小到大的顺序进行了排列每一行都包含着内存malloc出来的地址谁申请了内存申请的次数申请的size大小申请者在代码中的位置等一目了然。
我们一下就从图中的最后一行也就是占据系统内存最多的组件发现了异常点此时系统中还存在着982个timer占据着70K 的系统内存这个肯定是有问题的 4. 快速问题复现
快速复现问题是bug定位过程中非常重要的的一步。 由于压测过程是每5分钟断开路由器时间较长我们尝试重现构造测试用例来复现这一现象。由前面分析可知这一压测过程只跟厂商wifi 驱动有关。我们找到了2个通用接口来模拟这一过程 hal_wifi_suspend_station ---- 断开路由器操作会调用厂商底层的wifi disconnect netmgr_reconnect_wifi ---- 连接路由器操作会调用厂商底层的wifi connect
我们构建的测试case代码如下 while (1) {krhino_mm_overview(NULL); /*重点关注这一行*/aos_msleep(5000);hal_wifi_suspend_station(NULL);netmgr_reconnect_wifi();}
即在系统上电启动必要的网络初始化后开始以5s为周期循环压测 suspend 和 reconnect
请注意while循环里的第一行
krhino_mm_overview(NULL);
这个接口是维测对外API 调试接口之一会打印堆的相关统计。
维测调试API接口是debug的时候的重要手段之一加上这些接口出版本往往可以快速定位问题 详见 https://yuque.antfin-inc.com/aliosthings/mr5i1t/wupvbn#994230b2
这个接口打印如下所示举例 Heap Info
-----------------------------------------------------------
[HEAP]| TotalSz | FreeSz | UsedSz | MinFreeSz || 0x0004A838 | 0x00047E50 | 0x000029E8 | 0x00047E50 |
-----------------------------------------------------------
[POOL]| PoolSz | FreeSz | UsedSz | BlkSz || 0x00002000 | 0x00001E00 | 0x00000200 | 0x00000020 |
-----------------------------------------------------------
上面统计分成两部分HEAP与POOL。HEAP是总的统计POOL是HEAP的一部分。
HEAP与POOL的区别是当用户使用
aos_malloc(size)
来分配内存的时候size若小于32字节由RHINO_CONFIG_MM_BLK_SIZE宏指定在k_config.h中定义malloc会在POOL上固定分配32字节内存反之则在HEAP上分配用户定义size的内存。
HEAP中的内容含义
TotalSz堆的总大小。FreeSz当前堆的空闲大小。UsedSz当前堆的使用量即UsedSz TotalSz – FreeSz。MinFreeSz堆空闲历史最小值即TotalSz – MinFreeSz 便是堆历史使用量峰值。
出异常时可以利用该信息大致判断堆是否出现空闲内存不足的问题。
回到问题中来测试case跑起来后循环输出了每次网络连接后的系统内存使用情况如图 .... 5. 问题定位
可见系统系内存经过每次suspend 和 connect后都会减少并且减少的大小是固定的。这种情况是发生了稳定的内存泄漏厂商的WIFI驱动中存在着connect时 malloc的内存在suspend时没有free的情况导致了内存池泄漏早晚会发生内存耗尽。
由最早的log可知系统crach的时候也就是内存耗尽的时候系统中存在着982个timer没有释放所以我们重点关注timer的使用。由于厂商不提供源码这也是每次定位问题异常痛苦的原因之一没法在上层代码处直接加打印调试。在kernel timer处加上打印结果如下connect: suspend: 可以非常明显的看出connect时timer create了5次但是suspend的时候只delete了4次
问题定位到这里已经明确了问题根因timer少释放了一次。反馈给厂商后迅速解决。 6. 总结
这里结合使用了AliOS Things维测能力的几个方面
在设备端对接了内存异常的处理作为crash的第一现场打印出来PC端维测工具对设备端的crash log进行解析降低使用门槛维测API接口的使用是出版本进行debug的利器。
原文链接 本文为云栖社区原创内容未经允许不得转载。
