概述
公司有个程序存在缓慢的内存泄漏问题,今天针对性的对该问题进行排查,经过一番折腾,虽然没有确定根源,但是起码问题解决了,故博文记录,用于备忘
环境信息
操作系统:银河麒麟v10
架构平台:ARM
分析步骤
针对内存泄漏问题排查,个人直接上valgrind,利用valgrind挂着程序跑,然后不断地回放数据,最后在valgrind的报告中,显示存在内存泄漏
==3684709== 42 bytes in 6 blocks are definitely lost in loss record 382 of 1,116
==3684709== at 0x4865B28: operator new(unsigned long) (vg_replace_malloc.c:487)
==3684709== by 0x7A57E43: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long, unsigned long, char const*, unsigned long) (in /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.28)
==3684709== by 0x7A58E2B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long) (in /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.28)
==3684709== by 0x1BFD6F: .... (XXXX.cpp:547)
...
对比文件分析,发现对应cpp的代码行是一个字符串赋值操作
std::string szType = ""
for(...) //业务逻辑
{
switch(..)
{
case ..:
szType = "...."; //等于6字节的字符串,valgrind 检测到该行存在内存泄漏
break;
case ..
szType = "..."; //其他字符串大于6字节的字符串,并没有检测出内存泄漏
break;
default:
....
}
}
根据参考链接去怀疑,半信半疑的将字符串赋值改成字符数组使用strcpy代替,内存泄漏问题消失了…
根源猜想
可能是std::string短字符串优化导致,循环内多次赋值,某些情况下导致字符串赋值并没有释放原来的空间,有点像短字符串赋值过程中,分配了内存,但是在std::string下次赋值的时候,判断大小以为是栈存储,不对之前的内存释放,故而导致内存泄漏