背景
之前有讲过内存分析 [http://www.91dengdeng.cn/2019/05/07/windbg分析内存泄漏 ]
最近刚好又碰到一个问题,方式差不多,但过程复杂了些。
更新了一个版本,在后台的监控程序中可以看到内存一直在上涨,差不多1小时 100M左右。
方法
- 保存了dump,按照之前的方式查看
1 | 0:000> !heap -s |
堆块003b0000 提交了1.4G的内存
- 分析百分比
1 | 0:000> !heap -stat -h 003b0000 |
和之前不一样,没有哪块内存占用空间特别大,所以猜测应该是大量大小不一的内存导致的内存泄漏。
- 打印所有内存块
1 | 0:000> !heap -stat -h 003b0000 -grp S 1000 |
也就是说差不多有600个内存大小的申请,数量都不大,但是加起来有1.4G,该怎么找呢?
方法就是: 当内存上涨到 1.6G时,我们再打印一遍列表,然后比较1.4G和1.6G 两个的数量大小,比较下两者的差异,多出来的内存就是刚刚泄漏的内存。
结论
我对比了下,找到了一些怀疑点,然后通过1
!heap -flt s a397
获取内存的地址,并再memory中查看内存的内容,通过内存的内容找到了代码的怀疑点,并修复。
这个问题代码review时还真看不出来,UwlConstructRequest是第三方库,也没有函数说明。
1 | LPCONTEXT_HEAD lpContext2 = NULL; |