一个由进程内存布局异常引起的问题

前段时间业务反映某类服务器上更新了 bash 之后ssh 连上去偶发登陆失败客户端吐出错误信息如下所示图 - 0该版本 bash 为部门这边所定制但是实现上与原生版并没有不同那么这些错误从哪里来是 bash 的锅吗从上面的错误信息可以猜测异常是 bash 在启动过程中分配内存失败所导致看起来像是某些情况下该进程错误地进行了大量内存分配最后导致内存不足要确认这个事情比较简单动态内存分配到系统调用这一层上主要就两种方式 brk() 和 mmap(), 所以只要统计一下这两者的调用就可以大概估算出是否有大内存分配了。bash 是由 sshd 启动的于是 strace 跟踪了一下 sshd 进程结果发现异常发生时bash 分配的内存非常地少少到有时甚至只有几十字节也会失败几乎可以断定 bash 在内存使用上没有异常但在这期间发现一个诡异的现象Bash 一直只用 brk 在分配小内存brk() 失败后就直接退出了一般程序使用的 libc 中的 malloc (或其它类似的 malloc) 会结合 brk 和 mmap 一起使用【0】不至于 brk 一失败就分配不到内存顺手查看了下 bash 的源码发现它确实基于 brk 做了自己的内存管理并没有使用 malloc 或 mmap。但那并不是重点重点是即使是只使用 brk也不至于只能分配几十字节的内存。进程的内存布局进程的内存布局在结构上是有规律的具体来说对于 linux 系统上的进程其内存空间一般可以粗略地分为以下几大段【1】从高内存到低内存排列1、内核态内存空间其大小一般比较固定可以编译时调整但 32 位系统和 64 位系统的值不一样。2、用户态的堆栈大小不固定可以用 ulimit -s 进行调整默认一般为 8M从高地址向低地址增长。3、mmap 区域进程茫茫内存空间里的主要部分既可以从高地址到低地址延伸(所谓 flexible layout)也可以从低到高延伸(所谓 legacy layout)看进程具体情况【2】【3】。4、brk 区域紧邻数据段(甚至贴着)从低位向高位伸展但它的大小主要取决于 mmap 如何增长一般来说即使是 32 位的进程以传统方式延伸也有差不多 1 GB 的空间准确地说是 TASK_SIZE/3 - 代码段数据段参看 arch/x86/include/asm/processor.h 里宏 TASK_UNMAPPED_BASE 的定义)【4】5、数据段主要是进程里初始化和未初始化的全局数据总和当然还有编译器生成一些辅助数据结构等等)大小取决于具体进程其位置紧贴着代码段。6、代码段主要是进程的指令包括用户代码和编译器生成的辅助代码其大小取决于具体程序但起始位置根据 32 位还是 64 位一般固定(-fPIC, -fPIE等除外【5】)。以上各段(除了代码段数据段)其起始位置根据系统是否起用 randomize_va_space 一般稍有变化各段之间因此可能有随机大小的间隔千言万语不如一幅图图 - 1所以现在的问题归结为为什么目标进程的 brk 的区域突然那么小了先检查一下 bash 的内存布局图 - 2这个进程的内存布局和一般理解上有很大出入从上往下是低内存到高内存#1处为进程的代码段和数据段这两个区域一般处于进程内存空间的最低处但现在在更低处明显有动态库被映射了进来。#2处为 brk 的区域该区域还算紧临着数据段但是brk 与代码段之间也被插入了动态库而且更要命的是brk 区域向高处伸展的方向上动态库映射的区域贴的很近导致 brk 的区域事实上只有很小一个空间(0x886000 - 0x7ac000)。这并不是我们想要的内存布局我们想要的应该是长成下面这样的图 - 3看出来不同了没有两个 bash 进程都是 64 位的不同在于前者是 sshd 起的进程后者是我手动在终端上起起来的手动 cat /proc/self/maps 看了下 64 位的 cat 的进程的内存布局也是正常的图 - 4那 sshd 进程呢