Solaris 核心转储分析
我使用 pstack 来分析 Solaris 中的核心转储文件
我还能如何分析 Solaris 中的核心转储？
可以使用哪些命令来执行此操作？
从转储中还可以获得哪些其他信息？
I use pstack to analyze core dump files in Solaris
How else can I analyze the core dump from solaris?
What commands can be used to do this?
What other information will be available from the dump?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您可以使用 Solaris 模块化调试器、mdb 或 dbx。 mdb 附带 SUNWmdb（或 64 位版本的 SUNWmdb x）软件包。
核心文件是正在运行的进程崩溃时的映像。
根据您的应用程序是否使用调试标志进行编译，您将能够查看堆栈的图像，从而了解哪个函数导致了核心，获取传递给该函数的参数值，该值变量、分配的内存区域...
在最新的 Solaris 版本上，您可以使用 coreadm 命令配置核心文件将包含的内容； 例如，您可以将进程附加到映射的内存段。
请参阅 MDB 文档 和 dbx 文档。 一旦您了解了以下基础知识，GDB 快速参考卡也会很有帮助GDB。
You can use Solaris modular debugger,mdb, or dbx. mdb comes with SUNWmdb (or SUNWmdb x for the 64 bits version) package.
A core file is the image of your running process at the time it crashed.
Depending on whether your application was compiled with debug flags or not,you will be able to view an image of the stack, hence to know which function caused the core, to get the value of the parameters that were passed to that function, the value of the variables, the allocated memory zones ...
On recent solaris versions, you can configure what the core file will contain with the coreadm command ; for instance, you can have the mapped memory segments the process were attached to.
Refer to MDB documentation and dbx documentation. The GDB quick reference card is also helpful once you know the basics of GDB.
我想这个问题的任何答案都应该从一个简单的秘诀开始：
对于 dbx，秘诀是：
I guess any answer to this question should start with a simple recipe:
For dbx, the recipe is:
如果核心转储来自您编写或构建的程序，则使用您通常用来调试正在运行的应用程序的调试器。 它们都应该能够加载核心文件。 如果您对调试器不挑剔，并且您使用的是 Solaris，我会推荐 dbx。 它将有助于获取带补丁的 Sun Studio 的最新 FCS 版本，或者 Sun Studio 的最新 Express 版本。 如果您可以将核心文件加载到创建核心文件的同一系统上的调试器中，这也会非常有帮助。 如果库中的代码与创建核心文件时的代码不同，则堆栈跟踪在遍历库时将没有用处。 调试器还使用操作系统帮助程序库来理解 libthread 和运行时链接器数据结构，因此如果您需要在不同的计算机上加载核心文件，您需要确保操作系统上安装的帮助程序库与中的系统数据结构相匹配操作系统。 您可以在几年前编写的白皮书中找到有关这些系统库的所有您从未想知道的信息。
http://developers.sun.com/solaris/articles/DebugLibraries/DebugLibraries_content。 html
If the core dump is from a program you wrote or built, then use whichever debugger you would normally use to debug the running application. They should all be able to load core files. If you're not picky about debuggers, and you're using Solaris, I would recommend dbx. It will help to get the latest FCS version of Sun Studio with patches, or else the latest Express version of Sun Studio. It's also very helpful if you can load the core file into the debugger on the same system where the core file was created. If the code in the libraries is different from when the core file was created, then stack trace won't be useful when it goes through libraries. Debuggers also use OS helper libraries for understanding the libthread and runtime linker data structures, so IF you need to load the core file on a different machine, you'll want to make sure the helper libraries installed on the OS match the system data structures in the OS. You can find out everything you never wanted to know about these system libraries in a white paper that was written a few years ago.
http://developers.sun.com/solaris/articles/DebugLibraries/DebugLibraries_content.html
pflags 命令对于确定每个线程在核心转储时所处的状态也很有用。 通过这种方式，您通常可以查明问题所在。
The pflags command is also useful for determining the state each thread was in when it core dumped. In this way you can often pinpoint the problem.
我建议首先尝试 gdb，因为我认为它比本机 Solaris 调试器更容易学习基本任务。
I would suggest trying gdb first as it's easier to learn basic tasks than the native Solaris debuggers in my opinion.
可以使用GDB。
它可以发出转储之前尝试的呼叫。
http://sourceware.org/gdb/
http://en.wikipedia.org/wiki/GDB
拥有源代码非常棒，如果您可以重现错误，那就更好了，因为您可以使用它来调试它。
过去对我来说效果很好。
GDB can be used.
It can give the call that was attempted prior to the dump.
http://sourceware.org/gdb/
http://en.wikipedia.org/wiki/GDB
Having the source is great and if you can reproduce the errors even better as you can use this to debug it.
Worked great for me in the past.
使用 dbx 调试器附加到进程映像：
dbx [executable_file_name] [coredump_file_name]
重要的是，自转储核心以来可执行文件没有发生任何更改（即未重建）。
您可以使用 dbx 命令“where”查看堆栈跟踪以了解程序崩溃的位置。
您可以使用命令“up”和“down”在堆栈中上下移动，或者使用“frame [number]”跳转到确切的堆栈帧，数字在“where”的输出中看到。
您可以使用“print [expr]”命令打印变量或表达式的值。
玩得开心。
Attach to the process image using the dbx debugger:
dbx [executable_file_name] [coredump_file_name]
It is important that there were no changes to the executable since the core was dumped (i.e. it wasn't rebuilt).
You can see the stack trace to see where the program crashed with dbx command "where".
You can move up and down the stack with command "up" and "down", or jump to the exact stack frame with "frame [number]", with the numbers seen in the output of "where".
You can print the value of variables or expressions with "print [expr]" command.
Have fun.
我在我的 Solaris x86 盒子上找到了 dbx，
干杯！
I found dbx on my solaris x86 box at
Cheers!