使用libumem定位memory leak和memory corruption(3)-续

我明白了,我明白了为什么在(3)中发现了两处内存泄漏!先回顾一下(3)中的第二处泄漏的call stack, 注意这个stack是经过C++ 的符号mangle的,可读性很差,我首先用gc++filt处理一下:

> 080a7300$<bufctl_audit ! gc++filt
            ADDR          BUFADDR        TIMESTAMP           THREAD
                            CACHE          LASTLOG         CONTENTS
         80a7300          80a4fc0    d073d324dabb8                1
                          8090390          8075064                0
                 libumem.so.1`umem_cache_alloc_debug+0x16c
                 libumem.so.1`umem_cache_alloc+0xe1
                 libumem.so.1`umem_alloc+0x3f
                 libumem.so.1`malloc+0×23
                 libstdc++.so.6`operator new(unsigned int)+0×25
                 libstdc++.so.6`std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&)+0×43
                 libstdc++.so.6`std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned int, unsigned int, unsigned int)+0x5a
                 libstdc++.so.6`std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_safe(unsigned int, unsigned int, char const*, unsigned int)+0×28
                 libstdc++.so.6`std::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign (char const*, unsigned int)+0x3f
                 libstdc++.so.6`std::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator= (char const*)+0x2e
                 Foo::Foo(int) +0x5e
                 main+0×44
                 _start+0×80

略显恐怖哦-:)不要怕,我已经把关键部分用粗体标记出来了,可见这个call stack对应了源代码里面的 m_IDname=buf; 使用一个指向字符串的指针为std::string赋值。std::string的 operator=(char const*)的默认行为是deep copy,所谓deep copy是指要自己分配一块内存用于存放要存储的字符串。

在(3)中libumeme报的第一出内存泄漏根据计算是8个字节,计算的方法我在(2)中介绍数据结构的时候已经提到过了,这里不再熬述。这8个字节中4个字节是虚表指针,另外4字节是std::string本身所占的内存,本质上就是一根指针。这根指针指向真正存储字符串的内存。问题就在这里!

libumem报的第一处内存泄漏并不包含真正存储字符串的那块buffer!!

我们来验证一下,首先我们知道,一共分配了100个Foo实例,释放了99个,那另外的99个实例的内存分配情况如何呢?
> ::umalog ! less

T-0.000000000  addr=809dfc0  umem_alloc_16
         libumem.so.1`umem_cache_free_debug+0×135
         libumem.so.1`umem_cache_free+0x3f
         libumem.so.1`umem_free+0xd5
         libumem.so.1`process_free+0xfd
         libumem.so.1`free+0×14
         libstdc++.so.6`_ZdlPv+0×21
         _ZN3FooD0Ev+0×36
         main+0x8f
         _start+0×80

T-0.000000685  addr=80a4f80  umem_alloc_48
         libumem.so.1`umem_cache_free_debug+0×135
         libumem.so.1`umem_cache_free+0x3f
         libumem.so.1`umem_free+0xd5
         libumem.so.1`process_free+0xfd
         libumem.so.1`free+0×14
         libstdc++.so.6`_ZdlPv+0×21
         libstdc++.so.6`_ZNSs4_Rep10_M_destroyERKSaIcE+0x1b
         libstdc++.so.6`_ZNSsD1Ev+0x4d
         _ZN3FooD0Ev+0x1f
         main+0x8f
         _start+0×80

T-0.000001421  addr=80a4f80  umem_alloc_48
         libumem.so.1`umem_cache_alloc_debug+0x16c
         libumem.so.1`umem_cache_alloc+0xe1
         libumem.so.1`umem_alloc+0x3f
         libumem.so.1`malloc+0×23
         libstdc++.so.6`_Znwj+0×25
         libstdc++.so.6`_ZNSs4_Rep9_S_createEjjRKSaIcE+0×43
         libstdc++.so.6`_ZNSs9_M_mutateEjjj+0x5a
         libstdc++.so.6`_ZNSs15_M_replace_safeEjjPKcj+0×28
         libstdc++.so.6`_ZNSs6assignEPKcj+0x3f
         libstdc++.so.6`_ZNSsaSEPKc+0x2e
         _ZN3FooC1Ei+0x5e
         main+0×44
         _start+0×80

T-0.000002402  addr=809dfc0  umem_alloc_16
         libumem.so.1`umem_cache_alloc_debug+0x16c
         libumem.so.1`umem_cache_alloc+0xe1
         libumem.so.1`umem_alloc+0x3f
         libumem.so.1`malloc+0×23
         libstdc++.so.6`_Znwj+0×25
         main+0×30
         _start+0×80
上面显示了一个Foo实例从new到delete的完整的生命周期。一共牵涉到4次内存操作:分配Foo实例内存–>分配m_IDname所管理的用于真正存储字符串的内存–>释放字符串内存–>释放Foo实例。

我们来看看第二处泄漏内存的dump情况:
> 080a4fc0/16X
0x80a4fc0:                   2a           3a10bfd6         15                     15               0
(地址是80a4fd4 -> ) 206f6f46         656a624f        77207463        20687469    353d4449
                             babb0030         baddcafe        feedface        292f             80a7300
                             a91abbed

我用斜体标出了User Data Section的内容,老实讲我不记得 std::string内部在管理字符串是什么样的数据结构了,我也不想去挖代码。但是有一点注意了,注意我用蓝颜色标注的部分,这个部分的起始地址是 0x80a4fc0+0×14 = 0x80a4fd4。0x80a4fd4是什么?就是第一处内存泄漏的Foo实例中std::string的第一个4字节指针:

> 0809dfe0/8X  –> 0x0809dfe0 就是第一出泄漏buffer的起始地址
0x809dfe0: 10              3a10bff0        8050e30         80a4fd4          feedfabb
                fb1             80a3200         a91afaed

> 80a4fd4/S
0x80a4fd4:      Foo Object with ID=50

现在清楚了,上面蓝色部分的memory dump就是 "Foo Object with ID=50"的Ascii码。还记得字符’0′的ASCII是多少吗?是30!看看0xbb前最后的两个字节 0×30 0×00 正好是 ’0′和”。

好了,内存泄漏介绍完了,其实主要还是看经验,要了解自己的代码和数据结构,才能有效的使用像mdb这样比较底层的工具,有比较好的作用。下一篇我会介绍如何使用libumem+mdb处理 memory corruption。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值