迭代 glibc malloc 中所有区域中的所有块
任何对 glibc malloc 代码有一些基本了解的人都可以告诉我如何迭代所有的竞技场并找出哪些块没有被释放，即它们的 inuse 位被设置。我必须在退出进程时执行此操作。
或者
更确定的是，如果我们有一个 arena，我们可以访问其中分配的第一个块吗？
感谢大家抽出时间并回复。我很久以前就发布了这个问题。 “Phrack”在该问题中列出了一些黑客技术。我从中受益匪浅。
问候， 卡皮尔
Can anybody who has some basic idea on glibc malloc code please tell me how can i iterate over all the arenas and find out what are the chunks who are not freed i.e their inuse bit is set. This i have to do at the time of exit of the process.
or
more deterministically, if we have an arena, can we access the first chunk allocated in it?
thanks everybody for taking your time and responding back. I posted this question quite a long time back. 'Phrack' has some hacking techniques listed in there issues. I was benefitted from that.
regards,
Kapil
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
所有主要的 C 代码分析器通常都有某种 malloc 包装器，用于内存跟踪目的。如果不是类似的事情，您可能也必须做同样的事情来跟踪内存并使其独立于平台。
以下是一些示例：
跟踪 malloc 已分配的内存量
跟踪内存的简单 C 实现malloc/free？
您将必须添加额外的结构来存储分配的内存引用，以便您可以返回并迭代它们。我想您会想阅读与内存清理相关的算法。标记 N 扫描和引用计数是当今最流行的算法。 JVM 使用 Mark N Sweep。您还必须研究强链接和弱链接场景以及它们如何应用于您的 GC。
否则，如果您想节省时间而不编写自己的包装器，可以使用 valgrind 和 gprof 等工具来分析和评估内存使用情况。
老实说，我会看看 Boehm-Demers-Weiser 垃圾收集器。它已经写好了，并且基于广泛的研究。
刚刚注意到 BDWGC 已转移到 GitHub。
All the major c code profilers usually have some kind of wrapper around malloc for memory tracking purposes. You will probably have to do the same if not something similar for tracking memory and having it platform independent.
Here are some examples:
keeping track of how much memory malloc has allocated
Simple C implementation to track memory malloc/free?
You will have to add additional structures for storing allocated memory references so you can go back and iterate over them. I imagine you will want to read up on algorithms related to memory cleanup. Mark N Sweep and Reference-Counting are the most popular algorithms used today. The JVM uses Mark N Sweep. You will also have to research strong and weak linking scenarios and how they could apply to your GC.
Otherwise, if you want to save time and not write your own wrapper, tools like valgrind and gprof can be used to profile and evaluate memory usage.
Honestly I would check out out Boehm-Demers-Weiser Garbage Collecter. It's already written and is based of extensive research.
Just noticed BDWGC moved over to GitHub.
根据这个问题的表述，您似乎正在尝试重新发明一种与 标记-清除，使用 glibc 进行垃圾回收。这种努力是崇高的，但是垃圾收集器的存在可以很好地满足这一需求，如果这确实是您的最终目标，那么参考它们将为您节省大量的重新实现工作。
同时，您想要的功能不存在于C 规范，并在 glibc 中实现它有点困难，黑客。如果您希望继续推进您的实现，您需要咨询本地 glibc 的
malloc/malloc.c版本来确定正确的策略，因为不同的版本提供了非常不同的分配器级别保证。它可以通过分配器上的搭载代码来完成，但这似乎不是解决您所表达的问题的理想解决方案。尽管深入研究 C++，此线程包含有关如何编写的信息宝库你自己的内存管理器以及如何评估一个好的参考实现，如果你不想将自己束缚在 glibc 的内部，这是一个更可行的策略。我强烈建议您采用这种策略，因为它可以让您的应用程序面向未来，并抽象出您想要的功能（从而允许您将来插入不同的 C 库）。
祝您的申请顺利。
Based on the formulation of this question, it appears you're trying to reinvent an algorithm not unlike mark-sweep for garbage collection using glibc. The effort is noble, but garbage collectors exist to meet this need quite tidily, and referring to them will save you a tremendous amount of reimplementation effort if this is indeed your ultimate goal.
Meanwhile, the functionality you desire doesn't exist in the C specification, and implementing it in glibc is somewhat difficult and hacky. You'll want to consult your local glibc's version of
malloc/malloc.cto determine the correct strategy if you desire to continue moving forward with your implementation, on account of different versions providing very different allocator-level guarantees. It can be done by piggybacking code on the allocator, but this doesn't seem to be the ideal solution to your expressed problem.Despite being steeped in C++, this thread contains a treasure trove of information on how to write your own memory manager and how to evaluate a good reference implementation, which is a more workable strategy if you don't want to tether yourself to the internals of glibc. I would highly advise this strategy, because it future-proofs your application and abstracts away the functionality you desire (thus allowing you to drop in a different C library in the future).
Best of luck with your application(s).
这是 BlackHat 论文 很好地描述了 glibc 用于内存堆分配的内部结构。
arena.c 和 malloc.c 源代码是另一个值得关注的地方。
在代码中，
main_arenaglobal 是根。main_arena.next指向下一个 arena（如果有），main_arena.bins描述带有内存块的 bin。Here is a BlackHat paper with a good description of glibc's internal structures used for memory heap allocation.
arena.candmalloc.csources are another place worth looking at.In the code,
main_arenaglobal is the root.main_arena.nextpoints to the next arena (if any),main_arena.binsdescribe the bins with memory chunks.