我使用 pstack 分析 Solaris 中的核心转储文件
我还能如何分析来自 solaris 的核心转储?
可以使用哪些命令来执行此操作?
从转储中可以获得哪些其他信息?
您可以使用 Solaris 模块化调试器、mdb 或 dbx。mdb 附带 SUNWmdb(或 SUNWmdb x,对于 64 位版本)软件包。
核心文件是您正在运行的进程在崩溃时的映像。
根据您的应用程序是否使用调试标志编译,您将能够查看堆栈的图像,从而了解哪个函数导致核心,获取传递给该函数的参数的值,值变量,分配的内存区域......
在最近的 Solaris 版本上,您可以使用 coreadm 命令配置核心文件将包含的内容;例如,您可以将进程附加到映射的内存段。
如果核心转储来自您编写或构建的程序,则使用您通常用来调试正在运行的应用程序的任何调试器。他们都应该能够加载核心文件。如果您对调试器不挑剔,并且您使用的是 Solaris,我会推荐 dbx。这将有助于获得带有补丁的最新 FCS 版本的 Sun Studio,或者最新的 Express 版本的 Sun Studio。如果您可以将核心文件加载到创建核心文件的同一系统上的调试器中,这也非常有帮助。如果库中的代码与创建核心文件时不同,则堆栈跟踪在通过库时将无用。调试器还使用 OS 帮助程序库来理解 libthread 和运行时链接器数据结构,因此如果您需要在不同的机器上加载核心文件,您 我要确保安装在操作系统上的帮助程序库与操作系统中的系统数据结构相匹配。您可以在几年前编写的白皮书中找到您从未想知道的关于这些系统库的所有信息。
http://developers.sun.com/solaris/articles/DebugLibraries/DebugLibraries_content.html
我想这个问题的任何答案都应该从一个简单的食谱开始:
对于 dbx,配方是:
% dbx a.out core
(dbx) where
(dbx) threads
(dbx) thread t@3
(dbx) where
pflags命令还可用于确定每个线程在核心转储时所处的状态。通过这种方式,您通常可以查明问题所在。
我建议先尝试 gdb,因为在我看来,它比原生 Solaris 调试器更容易学习基本任务。
可以使用 GDB。
它可以发出在转储之前尝试的调用。
http://en.wikipedia.org/wiki/GDB
拥有源代码很棒,如果您可以更好地重现错误,因为您可以使用它来调试它。
过去对我很有帮助。
使用 dbx 调试器附加到进程映像:
dbx [executable_file_name] [coredump_file_name]
重要的是,自从核心被转储(即它没有被重建)以来,可执行文件没有任何变化。
您可以通过 dbx 命令“where”查看堆栈跟踪以了解程序在何处崩溃。
您可以使用命令“up”和“down”在堆栈上上下移动,或者使用“frame [number]”跳转到确切的堆栈帧,数字在“where”的输出中看到。
您可以使用“print [expr]”命令打印变量或表达式的值。
玩得开心。
我在我的 solaris x86 机器上找到了 dbx
/opt/SUNWspro/bin/dbx
干杯!