libc死机问题二(free死机)

一、简介

c语言本身并没有对内存的管理,在标准并没有明确的给出行为规定 本文只讨论glibc下的情况

1）glibc库提供了有限的管理，在操作非法时，会触发abort信号，或者由操作系统触发segmentfault信号

2）当程序的代码量较大时，内存问题的查找极为艰难

二、glibc free死机的分类

1）glibc detected *** free(): invalid pointer

字面意思是free一个无效指针；
产生的原因可能是内存越界，导致篡改了glibc库中的内存管理结构（换句话说可以称之为glibc库中metadata）；

所以在释放某一指针时，此指针所在的管理结构(metadata)无效，产生死机

2）glibc detected free(): invalid next size (fast)/（normal）
先解释下fast和normal，fast和normal是glibc内存管理里面的概念，小于64字节的内存 free后首先放到fast bins中，然后会放到unsorted bin中
最后才归并到small bins、large bins

产生的原因是，在free掉一个chunck后，在glibc进行chunck合并时，发现下一个chunck的大小无效

3）glibc detected double free or corruption
字面意思就是 两次free或者corruption on arena

总体来说就是出现了内存的非法操作（含越界、同步等），造成了整个arena的混乱

三、此类问题的查找方式

1）首先用debug分析coredump,看能否从死机堆栈上找到问题的原因（在嵌入式环境下，若堆栈在c库显示??，往往是因为c库已经被stip过了，可以重新编译debug版本的glibc库）,具体编译步骤：http://blog.csdn.net/jianchenglee/article/details/11724363

2）其次，若coredump无法解决此问题，可以使用静态代码检查工具如cppcheck，修改出现的错误

3）再次，进行统一的内存监控，采用红黑树进行内存监控，记录已分配的节点,在free时进行校验

4）此时，若问题无法解决，就认真梳理代码的流程，从逻辑看是否有存在风险 此步骤视个人对代码的熟悉程度，也可最先进行

5）实时内存调试工具 valgrind，若上述步骤都无法解决问题可以启用此工具进行实时内存调试，编译使用见本blog相关文章

四、问题总结

1）在程序代码量较为庞大，并且有大量产品在使用时，此种问题的出现往往是由于同步引起的（相对来说内存越界的问题容易查找些）

2）同步的概念指的是，一块内存（在glibc中是chunck的概念）先free掉，后又去使用读取 或者 写入，此时会破坏其他的chunck metadata信息，就会出现各种free死机（有时不只free死机，会引起程序死在其他位置）