Gai*_*ius 8 debugging rhel core-dump gdb
我们有使用 Python、Java 和 C++ 混合编写的进程，这些进程不时进行核心转储。它们在运行时根据需要以块的形式分配更多内存，并且当它们的分配提示超过 4G 时会崩溃（我猜malloc()没有检查的返回值）。
然而，根据 GDB 的说法，产生的核心转储被截断了——它们在操作系统中的大小没有限制，在磁盘上它们的大小在 2-3.8G 之间变化。
GDB 观察到大小不符合它的预期（大概包括失败的分配？）并放弃 - 但在 3.8G 的数据中肯定有一些有趣的东西？甚至可能是我需要回溯的整个堆栈！
我怎样才能说服 GDB 至少尝试一下，或者是否有替代工具可以从截断的核心中提取某些内容？
Sun Studio 12 网站上的这个简介似乎暗示它们基本上没用。
摘录 - http://docs.oracle.com/cd/E19205-01/819-5257/blabs/index.html如果您的核心文件被截断
如果您在加载核心文件时遇到问题，请检查您是否有被截断的核心文件。如果在创建核心文件时将核心文件的最大允许大小设置得过低，则 dbx 无法读取生成的截断的核心文件。在 C shell 中，您可以使用 limit 命令（请参阅 limit(1) 手册页）设置允许的最大核心文件大小。在 Bourne shell 和 Korn shell 中，使用 ulimit 命令（请参阅 limit(1) 手册页）。您可以在 shell 启动文件中更改核心文件大小的限制，重新获取启动文件，然后重新运行生成核心文件的程序以生成完整的核心文件。
如果核心文件不完整，并且缺少堆栈段，则堆栈跟踪信息不可用。如果缺少运行时链接器信息，则加载对象列表不可用。在这种情况下，您会收到关于 librtld_db.so 未初始化的错误消息。如果缺少 LWP 列表，则没有可用的线程信息、lwp 信息或堆栈跟踪信息。如果您运行 where 命令，您会收到一条错误消息，指出程序不是“活动的”。