mmap 区域从保留的堆栈空间分配？
在我们的产品中，我们使用 malloc 实现，该实现完全依赖于 mmap 进行内存分配。我们还合理使用分配。我们刚刚遇到了一个问题，mmap 将分配应该保留到堆栈空间的区域（因此，当我们的较大分配器之一溢出到 malloc 区域时，会导致非常糟糕的事情发生）。
我们的进程分配的限制是我们的虚拟机地址空间，而不是物理内存。我们在进程运行时观察了 /proc/*/maps 文件，并观察了 malloc 耗尽了所有可用的地址空间。它最终会在堆栈 rlimit-set 范围内分配地址，并最终将一个大的 alloca 延伸到其中。
我们尝试通过在启动时allocaing我们的整个堆栈限制来解决这个问题，但这并没有证明跨平台稳定（它在尝试访问allocad时出现段错误）我的 2.4 开发机上的内存，而它可以在 2.6 生产机上运行）。
有什么办法可以实际保留地址空间吗？还可以做什么？
In our product we use a malloc implementation that relies exclusively on mmap for memory allocation. We also do a fair use of allocaing. We've just encountered a problem where mmap will allocate regions that should be reserved to stack space (thus causing very bad things to happen when one of our larger alloca's spills into the malloc'd region).
The limitation of our process' allocation is our VM address space, not physical memory. We've watched the /proc/*/maps file as the process runs and watched malloc eat up any available address space. It eventually resorts to allocating addresses within the stacks rlimit-set range, and eventually a large alloca stretches into it.
We've tried to work around it by allocaing our entire stack limit at startup, but that hasn't proved stable across platforms (it segfaults trying to access the allocad memory on my 2.4 dev box, while it works on the 2.6 production machine).
Is there any way to actually reserve the address space? What else can be done?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
旧版本的 heartbeat 通过调用一次 memset()ed 1Kb 到 0xff 的递归函数来确保提交堆栈空间。 Heartbeat 这样做是为了能够 mlock() 它可能需要的所有内存。
Old versions of heartbeat ensured stack space was commited by calling a recursive function that memset()ed 1Kb at a time to 0xff. Heartbeat did this to be able to mlock() all memory it could potentially need.
这显然是最近记录的一个用于权限升级漏洞的安全漏洞。据称，较新的内核版本将被修补。
http://www.exploit-db.com/download_pdf/14696/
This is apparently an recently documented security vulnerability used in a privilege escalation exploit. Allegedly newer kernel versions will be patched.
http://www.exploit-db.com/download_pdf/14696/