我使用pstack在Solaris中分析核心转储文件

我还能如何分析solaris的核心转储？

可以使用哪些命令来执行此操作？

转储还将提供哪些其他信息？

解决方案

可以使用GDB。

它可以给出在转储之前尝试的呼叫。

http://sourceware.org/gdb/

http://en.wikipedia.org/wiki/GDB

拥有源代码非常有用，如果我们可以更好地重现错误，则可以使用它来调试它。

过去对我来说很棒。

我们可以使用Solaris模块化调试器，mdb或者dbx。 mdb随附SUNWmdb(对于64位版本，则为SUNWmdb x)。

核心文件是崩溃时正在运行的进程的映像。

根据应用程序是否使用调试标志进行编译，我们将能够查看堆栈的图像，从而知道哪个函数导致了内核，并获取传递给该函数的参数的值，即变量，分配的存储区...

在最新的solaris版本上，可以使用coreadm命令配置核心文件将包含的内容。例如，我们可以具有进程添加到的映射内存段。

请参考MDB文档和dbx文档。一旦我们了解GDB的基础知识，GDB快速参考卡也将很有帮助。

pflags命令对于确定每个线程在核心转储时所处的状态也很有用。这样，我们通常可以查明问题所在。

使用dbx调试器添加到过程映像：

dbx [可执行文件名] [coredump文件名]

自从内核被转储(即未重建)以来，对可执行文件进行任何更改都非常重要。

我们可以看到堆栈跟踪，以查看程序在何处使用dbx命令" where"崩溃。

我们可以使用命令" up"和" down"在堆栈中上下移动，或者使用" frame [number]"跳转到确切的堆栈框架，并在" where"的输出中看到数字。

我们可以使用" print [expr]"命令来打印变量或者表达式的值。

玩得开心。

如果核心转储来自我们编写或者构建的程序，请使用通常用于调试正在运行的应用程序的调试器。他们都应该能够加载核心文件。如果我们对调试器不挑剔，并且使用的是Solaris，则建议我们使用dbx。这将有助于获得带有修补程序的Sun Studio的最新FCS版本，或者获得Sun Studio的最新Express版本。如果可以将核心文件加载到创建核心文件的系统上的调试器中，这也非常有帮助。如果库中的代码与创建核心文件时的代码不同，则堆栈跟踪在通过库时将无用。调试器还使用OS帮助程序库来了解libthread和运行时链接程序的数据结构，因此，如果需要将核心文件加载到另一台计算机上，则需要确保OS上安装的帮助程序库与以下文件中的系统数据结构匹配：操作系统。我们可以在几年前编写的白皮书中找到有关这些系统库的所有不想知道的信息。

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