/proc/sys/vm/max_map_count耗尽时，调用glibc 2.11.3 free()导致程序crash，问题追踪和解决

1. 问题

在客户环境下，当我们的程序消耗较大内存时，会偶尔crash。

通过gdb分析，程序core dump在malloc/free函数内。

当把/proc/sys/vm/max_map_count 从65530增加到131070，程序再也不crash。

相关命令 echo 131073 > /proc/sys/vm/max_map_count

2.  core dump 分析

Thread 1 (Thread 20074): #0  0x00007fbb77afd6d5 in raise () from/lib64/libc.so.6 

#1  0x00007fbb77afecb1in abort () from /lib64/libc.so.6 

#2 0x00007fbb77b43a0d in __malloc_assert () from /lib64/libc.so.6 #3  0x00007fbb787ea6a8 in 

#3 不再给出，涉及保密

...

...

运行环境是SUSE 11 SP3, 其glibc 版本是2.11.3。

通过读glibc 2.11.3 代码，发现一个可疑点：

https://github.com/lzueclipse/learning/blob/master/c_cpp/glibc-2.11.3/malloc/malloc.c#L3552

当free()时，如果/proc/sys/vm/max_map_count 被耗尽，那么munmap系统调用会失败，就会导致assert，并core dump。

下面我们来试图证明这个分析是正确的。

3. 通过Google搜索找到一个类似的问题