Question

我正在调试一个在我的mac上导致内核转储的驱动程序。它显示了由一系列地址组成的长回溯：

panic(cpu 6 caller 0xffffff8004dc9986): trying to interlock destroyed mutex  
(0xffffff8049deedb0)
Backtrace (CPU 6), Frame : Return Address
0xffffff93b1c8bb50 : 0xffffff8004ce5307 
0xffffff93b1c8bbd0 : 0xffffff8004dc9986 
0xffffff93b1c8bbe0 : 0xffffff8004d099eb 
0xffffff93b1c8bc20 : 0xffffff7f85604899 
0xffffff93b1c8bc50 : 0xffffff800519776b 
0xffffff93b1c8bc90 : 0xffffff80051f336c 
0xffffff93b1c8be00 : 0xffffff8005205fb3 
0xffffff93b1c8bef0 : 0xffffff80052028a6 
0xffffff93b1c8bf60 : 0xffffff800522afd1 
0xffffff93b1c8bfb0 : 0xffffff8004df4b16

我认为由于计算机重新启动，因此地址转换现在无用，因为在每次启动迭代后内存映射可能会有所不同。

是否有任何选项可以将相关方法与回顾中的每个地址相匹配，或者提前设置适当的配置？谢谢

Answer 1

是的，你绝对可以象征内核恐慌痕迹，但为了追溯，你需要恐慌日志中的更多信息，而不仅仅是原始堆栈跟踪。如你所说，地址只对加载地址有意义。

Apple关于该主题的官方文档TN2063有点过时了。它给出的例子来自Darwin 9，即OS X 10.5，自那时起事情发生了一些变化，引入了内核ASLR和kext UUID。我会尝试给你一个非常快速的最新指南。

<强> 1。简单方法

如果您的恐慌是可重现的，最简单的方法是让内核为您进行符号化。使用内核引导参数keepsyms=1意味着内核不会丢弃内核和kext图像中存储的任何符号，并且会在发生混乱时查找堆栈跟踪中的返回指针。

只需将keepsyms=1添加到/Library/Preferences/SystemConfiguration/com.apple.Boot.plist中的内核标志设置或boot-args NVRAM变量即可。重新启动，任何后续的恐慌都将自动进行符号化。您可以通过c++filt命令行实用程序运行受损的C ++符号，以获得正确的C ++函数签名。例如，

$ echo __ZN32IOPCIMessagedInterruptController17registerInterruptEP9IOServiceiPvPFvS2_S2_S2_iES2_ | c++filt
IOPCIMessagedInterruptController::registerInterrupt(IOService*, int, void*, void (*)(void*, void*, void*, int), void*)

<强> 2。手动方式

如果你有一种无法解释的，神秘的恐慌，你似乎无法复制，那么这种简单的方法并没有多大帮助。

在堆栈跟踪之后，立即查找以＆＃34;回溯中的内核扩展名开头的部分：＆＃34;在恐慌日志中。这将列出恐慌中涉及的任何关键字，包括其加载地址，版本和UUID。地址作为范围给出;起始地址位于->的左侧，位于@之后。最后一个地址位于箭头右侧。使用此信息，您应该能够识别堆栈跟踪中列出的每个代码地址（右侧的十六进制数字）所在的kext。

除了他们中的一些人不匹配任何kext。除了在某些奇怪的情况下，这些将来自内核本身。内核映像（内核或mach_kernel）的加载地址进一步缩小，它表示＆＃34;内核文本库：＆＃34;

一旦知道要查看哪个可执行映像，atos命令就会让您对每个地址进行符号化。

例如，让我们说我们恐慌这条线：

…
0xffffff8098c1bba0 : 0xffffff7f80c343f2
…

我们也发现：

  Kernel Extensions in backtrace:
     com.apple.iokit.IOPCIFamily(2.9)[BDA92C3B-AD86-33E5-A7F1-1603465350A7]@0xffffff7f80c1a000->0xffffff7f80c4dfff

请注意，0xffffff7f80c343f2大于（或等于）0xffffff7f80c1a000且小于（或等于）0xffffff7f80c4dfff，因此相关代码位于IOPCIFamily中。

这引出了以下命令（及其输出）：

$ atos -o /Library/Developer/KDKs/KDK_10.10.5_14F27.kdk/System/Library/Extensions/IOPCIFamily.kext/IOPCIFamily -l 0xffffff7f80c1a000 0xffffff7f80c343f2
IOPCIMessagedInterruptController::registerInterrupt(IOService*, int, void*, void (*)(void*, void*, void*, int), void*) (in IOPCIFamily) (IOPCIMessagedInterruptController.cpp:85)

-o指定可执行文件。这通常位于.kext包的Contents / MacOS /子目录中，但Apple的一些kexts直接在.kext目录中。对于内核本身的函数，提供内核映像，例如/Library/Developer/KDKs/KDK_10.10.5_14F27.kdk/System/Library/Kernels/kernel。

-l参数指定加载地址。即开始/文字基础。

最后，只列出要在该文件中进行符号化的所有地址。在这种情况下，只有一个，但你可以列出多个。您也可以从stdin读取它们（如果命令行中没有列出）。

有了这个，您应该能够解码整个跟踪。

关于UUID的说明

您会注意到跟踪中的每个kext和内核本身都列出了UUID。这对于确保您使用正确的版本进行符号化非常方便。这是Mach-O二进制文件中LC_UUID加载程序命令的UUID。您可以使用以下方法检查UUID是否为kext：

$ otool -l /Library/Developer/KDKs/KDK_10.10.5_14F27.kdk/System/Library/Extensions/IOPCIFamily.kext/IOPCIFamily | grep uuid
    uuid BDA92C3B-AD86-33E5-A7F1-1603465350A7

确认用于符号化的kext确实与恐慌中的kext匹配。如果您遇到奇怪的版本问题，或者您遇到了kext缓存问题，那么这非常棒。

OS X内核恐慌诊断。如何翻译回溯地址

1 个答案: