core分析-间接的指针误操作

 

core分析-间接的指针误操作

2013-11-26 17:22  528人阅读  评论(0)  收藏  举报

  分类：

 

c++（19） 

版权声明：本文为博主原创文章，未经博主允许不得转载。

先来看下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
#17 ExpandByElem (this=0x99b7ea48, aElem=0x999634c8) at .../BackgroundElement.h:64

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

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

分析方法：

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

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

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

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

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

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

一是下标越界

二是指针越界

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