Glibc的一个潜在的坑

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/jqh9804/article/details/80589539

问题描述:
https://sourceware.org/ml/libc-help/2016-09/msg00000.html

为什么会出现内存无法真正回收给系统呢?答案是永远不会回收给系统

当需要分配的内存小,达不到需要走mmap内存模式时,glibc会用brk()分配内存,如果brk()失败了呢?正如链接里代码,强行在堆顶部mmap块内存(之后的brk()会强制失败),此时glibc会被迫mmap后备内存,并且从堆顶部开始分配mmap内存,但是这块管理内存的方式又是按照heap来管理,各种分块缓存都是有的。但是到了free()时,这块内存永远不会回收给系统。

源码中回收内存是systrim()函数,其中:

systrim():
/*
Only proceed if end of memory is where we last set it.
This avoids problems if there were foreign sbrk calls.
*/
current_brk = (char*)(MORECORE(0));
if (current_brk == (char*)(av->top) + top_size) {

可见,我们现在这块内存,是mmap的,起始地址永远不会等于sbrk(0)返回的堆顶部。那么就永远不会回收。

虽然只是人工构造的特殊情况,但是如果对glibc有特殊玩法就要注意了,至于手工调用brk()造成glibc的堆不连续,会不会出现类似极端情况,目前这部分代码我没跟踪,但是感觉有猫腻。

猜你喜欢

转载自blog.csdn.net/jqh9804/article/details/80589539