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

当/proc/sys/vm/max_map_count达到65530,使用glibc 2.11.3的free()可能导致程序崩溃。通过分析core dump和glibc源码,发现munmap系统调用失败会触发assert。测试表明,在SUSE 11 SP3上(glibc 2.11.3)超过max_map_count会导致崩溃,而在SUSE 12(glibc 2.19)上问题已修复。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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搜索找到一个类似的问题

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值