coredump之栈溢出

1.栈溢出引发的core往往出现出现在递归调用中。

gdb时看到的特征是：

栈缺失，当前栈地址不可读。 根据栈是逆向生长的特点（栈逆向生长，所以很容易出现类似数组溢出覆盖率函数返回地址，导致函数退出地址出错），可以通过地址增加找到栈的位置。

找到有效栈后往往会发现重复的地址不断重复，这个实际就是递归造成的，根据函数地址就可以顺着找到对应的几个形成递归调用的函数了。进而分析出形成递归的流程。

2.栈溢出引发的core也可以出现在单个栈变量过大。

gdb看同样是栈缺失，不过这个因为不是函数调用导致，往往问题就出现在当前代码行所分配的变量。

之前遇到过一个问题，某个进程在正常情况下可以启动，但某些特定情况下（比如通过其他进程拉起）就会core掉，core的位置就是刚进入main函数，感觉很蒙。

最终分析结果main函数下面直接就是生成一个生成一个对象，因为是被模板封装的，之前没注意到这个局部对象的分配。实际发现这个对象竟然有80MB，超过了linux默认栈大小。而该进程在通过它自己的启动脚本启动时通过ulimit -s修改了栈的大小，然后在其他进程拉起该进程时则是直接继承父进程的栈设置，无法满足80MB以上时就会导致无法启动。

3.ulimit -s确实会影响进程的栈空间大小，但要注意它所能影响的仅仅是该进程的主线程的栈空间，因为只有主线程是通过shell拉起的，进程中的各种子线程都是由主线程调用api创建的，子线程的占空间大小也是由主线程控制的。

4.栈溢出引发的core实际上也就是signal 11, Segmentation fault. Signal 11, or officially know as "segmentation fault", means that theprogram accessed a memory location that was not assigned. That'susually a bug in the program.  即访问未分配的内存，就是在进程空间中没有映射到物理内存的的地址。 因此栈溢出并不一定立即core。而是恰好栈溢出之后走到的地址还是该进程未分配过的地址才会core掉。

5.默认情况下，通过glibc分配内存时默认是以128K为单位分配内存的，即使仅分配一个char，也是得分配128K。在操作系统看来，程序就是占用了128K的内存，也就会给进程创建出128K内存的映射表，所以并非访问到一个程序未分配地址就会core，因为操作系统看来这128K内存都是进程的。 当然这个锅应该由glibc背的，并非操作系统。但glibc也是好心，减少分配块数降低操作系统压力才这么做的 囧。

模拟栈溢出core的示例：

Linux下和core说再见之：栈溢出