比较隐秘的内存问题

share_ptr/auto_ptr 避免这样使用：强引用上的回环指针会导致内存泄露，可在destructor人为拆散

症状：方便的话在ref_count加个打印就知道了，可以在对象析构加打印提醒是否有对象一直没被析构。

基类析构函数非virtual  针对base *pt = new derived; delete pt的情况

栈溢出.下标越界，栈区，一是越界离谱低于栈区最低地址导致的挂掉，一是改了其他栈内存导致的诡异异常

症状：体现在一个程序跑了几次挂在不同的地方，比如stl容器析构等

多线程环境下lock没处理好导致的 一边write一边使用的情况，指针用着用着变空，效果比较恐怖

症状：偶尔程序挂掉，可以尝试用脚本模拟客户端进行围剿

tcmalloc/gmalloc要是吃不透就尽量省着用new出来的对象，用factory管理着，经常new / delete表示频繁的更多未知的内存分配或遗漏，至少可以减低增长率延长寿命。

注意线程安全和不可重入函数！

堆溢出

症状：每次malloc的时候加上一个reserved size问题就不重现，堆指针越界所致，慢慢查吧，代码分支模块等分开排查！

fg.

先来看下core的堆栈信息：

(gdb) bt 20
#0  0x06d99e7c in __exchange_and_add (__mem=0xc08a69d8, __val=-1) at ...../../../../include/c++/4.6.2/ext/atomicity.h:48
#1  __exchange_and_add_dispatch (__val=-1, __mem=0xc08a69d8) at ...../../../../include/c++/4.6.2/ext/atomicity.h:81
#2  _M_dispose (__a=..., this=0xc08a69d0) at ...../../../../include/c++/4.6.2/bits/basic_string.h:240
#3  ~basic_string (this=0x99962fb8, __in_chrg=<optimized out>) at ...../../../../include/c++/4.6.2/bits/basic_string.h:534
#4  ~Property (this=0x99962fb0, __in_chrg=<optimized out>) at .../OutputElement.h:184
#5  ~_List_node (this=0x99962fa8, __in_chrg=<optimized out>) at ...../../../../include/c++/4.6.2/bits/stl_list.h:105
#6  destroy (__p=0x99962fa8, this=<optimized out>) at ...../../../../include/c++/4.6.2/ext/new_allocator.h:118
#7  _M_clear (this=0x99962f90) at ./../../../include/c++/4.6.2/bits/list.tcc:76
#8  ~_List_base (this=0x99962f90, __in_chrg=<optimized out>) at .../../../../../include/c++/4.6.2/bits/stl_list.h:372
#9  ~list (this=0x99962f90, __in_chrg=<optimized out>) at ..../include/c++/4.6.2/bits/stl_list.h:429
#10 ~OutputElement (this=0x99962ed8, __in_chrg=<optimized out>) at .../OutputElement.h:218
#11 OutputElement::~OutputElement (this=0x99962ed8, __in_chrg=<optimized out>) at .../OutputElement.h:218
#12 0x06d974e0 in Release (this=0x99962ed8) at ../RefObject.h:88
#13 RefObject::Release (this=0x99962ed8) at ../RefObject.h:85
#14 0x06dd3c12 in assign_assuming_AddRef (newPtr=0x999634c8, this=0x99b7eb38) at .../nsAutoPtr.h:895
#15 assign_with_AddRef (rawPtr=0x999634c8, this=0x99b7eb38) at .../nsAutoPtr.h:879
#16 operator= (rhs=0x999634c8, this=0x99b7eb38) at .../nsAutoPtr.h:963

上面目录内容用...代替一些目录

初次分析，一般都会对容器的唔使用或者对象指针的使用或者异步操作所导致等进行排查，但本次遇到的问题不属于上面的情况导致stl的容器析构有问题，有可能是栈内容被c++恶心的指针误操作所导致

分析方法：

1、对主干分支的代码进行回滚排查，二分法定位出出现问题的日期并揪出问题代码

2、对程序的各个模块进行分开排查，对出现问题的模块进行代码注释定位

结果，发现在写png图片的时候，constructor对buffer的大小进行了memset，但是写图片的时候没做好异常处理，有y坐标是负数的少数情况，导致buffer指针写越界，操作了stl容器的内容。

这种情况很容易导致定位问题目标不准确结果查了很长时间未果，也不好定位原因！

针对这种情况，查看堆栈里面的指针信息，就会出现一些类似0x80不可读写等的指针信息相当诡异，其实是栈内容被修改导致的。

所以针对该问题，一般有两种情况导致：

一是下标越界

二是指针越界

对于堆或者栈，只要写操作没有到某个访问，就算你误操作超出范围了也被蒙在鼓里，比较恶心，所以写代码还是需要仔细。