巨大 coredump 的 gdb 内存使用情况
当使用 gdb 打开 coredump 时，gdb 会尝试将完整的 coredump 加载到内存中吗？
我在我们的一个临时系统上发现了一个大小为 35Gb 的核心转储。我们的操作说明要求使用 gdb 创建回溯。我担心 gdb 会尝试将完整的核心转储加载到内存中，并通过耗尽所有可用内存来使暂存区域变得不可用。
我们在 RedHat EL 5 / 64 位安装上使用 gdb 7.0.1。
When opening a coredump with gdb, will gdb try to load the full coredump into memory?
I've found a coredump with a size of 35Gb on one of our staging systems. Our operating instructions call for the creation of a backtrace using gdb. I'm afraid gdb will try to load the full coredump into memory and render the staging area unusable by using up all available memory.
We're using gdb 7.0.1 on a RedHat EL 5 / 64bit installation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不。
即使不加载整个核心转储，GDB也会消耗一些内存，因此您可能会对您的登台系统产生影响。如果您无法承受效果，那么您需要修改您的“操作程序”，例如将核心移至不同的系统并在那里进行分析。请注意：如果您的可执行文件使用动态链接，则必须安排动态库在生成核心转储和分析它时完全匹配。
No.
Even without loading the entire core dump, GDB will consume some memory, so you may have an effect on your staging system. If you can't afford to have an effect, then you need to modify your "operating procedures", e.g. move the core to a different system and analyze it there. Beware: if your executable uses dynamic linking, you must arrange for the dynamic libraries to match exactly at the time when core dump was generated and when it is analyzed.