stackwalker加载所有符号文件，但仍然不表示任何符号

时间：2014-05-08 08:58:09

标签： google-breakpad

我可能做错了什么，但我无法弄清楚这一点。

我有一个简单的崩溃小型转储，在Windows上生成。 如果我在visual studio中打开转储，它会毫无问题地加载并显示崩溃线。 但是我无法在minidump_stackwalker中表达它。

我确实创建了一个符号存储库文件夹，里面我有： 符号/ myapplication.pdb / 67892B042C8F4CCFAA6BE53445F9B2141 / myapplication.sym 以及所有： 符号/ wkernel32.pdb / XXXXXX / wkernel32.sym 应用程序使用的等。

当我调用“minidump_stackwalk mycrash.dmp symbols”时，stderr显示simple_symbol_supplier正确找到所有符号并加载它们。 但是，输出仍然是堆栈，没有任何符号。

我还尝试在linux和MacOSX上编译并运行minidump_stackwalk，但结果是一样的。

我做错了什么？

stackwalk的stderr输出如下所示：

2014-05-08 16:44:48: minidump_processor.cc:235: INFO: Processing minidump in file 604c29d0-318a-4321-9e40-b0198085c17d.dmp
2014-05-08 16:44:48: minidump.cc:3258: INFO: Minidump opened minidump 604c29d0-318a-4321-9e40-b0198085c17d.dmp on fd 3
2014-05-08 16:44:48: minidump.cc:3303: INFO: Minidump not byte-swapping minidump
2014-05-08 16:44:48: minidump.cc:1726: ERROR: MinidumpModule could not determine debug_file for C:\Windows\winsxs\x86_microsoft.vc90.mfcloc_1fc8b3b9a1e18e3b_9.0.30729.6161_none_49768ef57548175e\MFC90ENU.DLL
2014-05-08 16:44:48: minidump.cc:1794: ERROR: MinidumpModule could not determine debug_identifier for C:\Windows\winsxs\x86_microsoft.vc90.mfcloc_1fc8b3b9a1e18e3b_9.0.30729.6161_none_49768ef57548175e\MFC90ENU.DLL
2014-05-08 16:44:48: minidump_processor.cc:103: INFO: Minidump 604c29d0-318a-4321-9e40-b0198085c17d.dmp has CPU info, OS info, Breakpad info, exception, module list, thread list, dump thread, and requesting thread
2014-05-08 16:44:48: minidump_processor.cc:137: INFO: Looking at thread 604c29d0-318a-4321-9e40-b0198085c17d.dmp:0/24 id 0x1570
2014-05-08 16:44:49: basic_source_line_resolver.cc:223: INFO: Loading symbols for module C:\Program Files\MyApplication\myapplication.exe from buffer
2014-05-08 16:44:49: basic_source_line_resolver.cc:223: INFO: Loading symbols for module C:\Windows\System32\user32.dll from buffer
2014-05-08 16:44:49: basic_source_line_resolver.cc:223: INFO: Loading symbols for module C:\Windows\System32\kernel32.dll from buffer
2014-05-08 16:44:49: basic_source_line_resolver.cc:223: INFO: Loading symbols for module C:\Windows\System32\ntdll.dll from buffer
2014-05-08 16:44:49: minidump_processor.cc:137: INFO: Looking at thread 604c29d0-318a-4321-9e40-b0198085c17d.dmp:1/24 id 0xbb4
...
2014-05-08 16:44:49: minidump_processor.cc:229: INFO: Processed 604c29d0-318a-4321-9e40-b0198085c17d.dmp
2014-05-08 16:44:49: minidump.cc:3232: INFO: Minidump closing minidump on fd 3

输出如下：

Operating system: Windows NT
                  6.1.7601 Service Pack 1
CPU: x86
     GenuineIntel family 6 model 15 stepping 6
     2 CPUs

Crash reason:  EXCEPTION_ACCESS_VIOLATION
Crash address: 0x0

Thread 0 (crashed)
 0  myapplication.exe + 0x6d0aa7
    eip = 0x01500aa7   esp = 0x0023eef4   ebp = 0x0023eefc   ebx = 0x0505f9bc
    esi = 0x0505f9bc   edi = 0x00000000   eax = 0x0514fe33   ecx = 0x0003c11d
    edx = 0x00000003   efl = 0x00010202
    Found by: given as instruction pointer in context
 1  myapplication.exe + 0x146fb
    eip = 0x00e446fc   esp = 0x0023ef04   ebp = 0x0023ef20
    Found by: previous frame's frame pointer
 2  myapplication.exe + 0x127b1
    eip = 0x00e427b2   esp = 0x0023ef28   ebp = 0x0023ef4c
    Found by: previous frame's frame pointer
...

2 个答案:

答案 0 :(得分：8)

一些额外的信息：

http://www.chromium.org/developers/decoding-crash-dumps

http://blog.inventic.eu/2012/08/qt-and-google-breakpad/

我的核心问题是在符号文件夹中我没有​​与我的二进制文件具有完全相同名称的文件夹。只需将所有内容命名为二进制。关于linux的例子：

$google-breakpad/src/tools/linux/dump_syms/dump_syms ./MyBinary > MyBinary.sym
$head -n1 MyBinary.sym

它会打印类似

的内容 
MODULE Linux x86_64 6EDC6ACDB282125843FD59DA9C81BD830 MyBinary

现在做出类似的事情：

$ mkdir -p ./symbols/MyBinary/6EDC6ACDB282125843FD59DA9C81BD830
$ mv test.sym ./symbols/MyBinary/6EDC6ACDB282125843FD59DA9C81BD830

最后

google-breakpad/src/processor/minidump_stackwalk 09fd98ec-d55c-29e1-4ae067b0-4aaec0d6.dmp ./symbols

或者您可以使用简单的脚本：

使用示例：

./script.py --dump_syms=/home/user/projects/libs/google-breakpad/src/tools/linux/dump_syms/dump_syms \
--minidump_stackwalk=/home/user/projects/libs/google-breakpad/src/processor/minidump_stackwalk \
--binary=./MyBinary \
--output_dir=/home/user/.config/MyBinary/dumps/
--dump_file=/home/user/.config/MyBinary/dumps/75ad100c-ef7c-c4eb-1da750f8-45586148.dmp

脚本：

#!/usr/bin/python

import sys
import getopt
import os
import errno
from os.path import basename

def make_sure_path_exists(path):
    try:
        os.makedirs(path)
    except OSError as exception:
        if exception.errno != errno.EEXIST:
            raise


def main(argv):

    dumpSymsExe = ""
    binary = ""
    outputDir = ""
    minidumpExe = ""
    dumpFile = ""

    try:                                
        opts, args = getopt.getopt(argv, "", ["help", "dump_syms=","binary=",
                                              "output_dir=","dump_file=",
                                              "minidump_stackwalk="])
    except getopt.GetoptError:
        print ("Please pass correct arguments!")
        sys.exit(2)  

    for opt, arg in opts:
        if opt == "--dump_syms":
            dumpSymsExe = arg
        if opt == "--binary":
            binary = arg
        if opt == "--output_dir":
            outputDir = arg
        if opt == "--dump_file":
            dumpFile = arg
        if opt == "--minidump_stackwalk":
            minidumpExe = arg

    outputFile =  outputDir + basename(binary) + ".sym"
    command = '{0} {1} > {2}'.format(dumpSymsExe,binary,outputFile)

    print ('Running {0}'.format(command) )
    os.system(command)

    symFile = open(outputFile, 'r')
    firstLine = symFile.readline()

    print ('First line {0}'.format(firstLine))
    lineArguments = firstLine.split(' ')
    print ('Magic file {0}'.format(lineArguments[-2]))

    symbolsDir = (outputDir + "symbols/" + basename(binary) + "/" +
                  lineArguments[-2] + "/")

    make_sure_path_exists(symbolsDir)
    os.rename(outputFile,symbolsDir + basename(outputFile))

    command = '{0} {1} {2}'.format(minidumpExe,dumpFile,outputDir + "symbols")
    print command
    os.system(command)

if __name__ == "__main__":
    main(sys.argv[1:])

另一个事情可能是，如果你看一下详细的崩溃信息的结尾，你会看到类似的东西：

0x7f75e2695000 - 0x7f75e28aefff  librtmp.so.0  ???
0x7f75e28af000 - 0x7f75e2ae1fff  libidn.so.11.6.11  ???
0x7f75e2ae2000 - 0x7f75e2d0bfff  libexpat.so.1.6.0  ???
0x7f75e2d0c000 - 0x7f75e2fadfff  libfreetype.so.6.10.1  ???
0x7f75e2fae000 - 0x7f75e31b7fff  libXrandr.so.2.2.0  ???
0x7f75e31b8000 - 0x7f75e33bbfff  libdl-2.17.so  ???
0x7f75e33bc000 - 0x7f75e35c7fff  libdrm.so.2.4.0  ???
0x7f75e35c8000 - 0x7f75e37cdfff  libXxf86vm.so.1.0.0  ???
0x7f75e37ce000 - 0x7f75e39ebfff  libxcb.so.1.1.0  ???
0x7f75e39ec000 - 0x7f75e3bf0fff  libxcb-dri2.so.0.0.0  ???
0x7f75e3bf1000 - 0x7f75e3e07fff  libxcb-glx.so.0.0.0  ???
0x7f75e3e08000 - 0x7f75e4009fff  libX11-xcb.so.1.0.0  ???
0x7f75e400a000 - 0x7f75e420ffff  libXfixes.so.3.1.0  ???
0x7f75e4210000 - 0x7f75e4412fff  libXdamage.so.1.1.0  ???
0x7f75e4413000 - 0x7f75e4624fff  libXext.so.6.4.0  ???
0x7f75e4625000 - 0x7f75e4849fff  libglapi.so.0.0.0  ???
0x7f75e484b000 - 0x7f75e4aa9fff  libcurl-gnutls.so.4.3.0  ???  (WARNING: No symbols, libcurl-gnutls.so.4.3.0, B662FA5595A461FACCB60A9D323597830)
0x7f75e4aaa000 - 0x7f75e4d26fff  libGLEW.so.1.8.0  ???
0x7f75e4d2b000 - 0x7f75e505ffff  libX11.so.6.3.0  ???
0x7f75e5060000 - 0x7f75e5278fff  libz.so.1.2.8  ???
0x7f75e5279000 - 0x7f75e54b4fff  libfontconfig.so.1.7.0  ???
0x7f75e54b5000 - 0x7f75e56c5fff  libglfw.so.2.6  ???
0x7f75e56c6000 - 0x7f75e5a88fff  libc-2.17.so  ???  (WARNING: No symbols, libc-2.17.so, 8A0DCFA21992EC412D98B231AF91DC1D0)
0x7f75e5a8e000 - 0x7f75e5ca3fff  libgcc_s.so.1  ???
0x7f75e5ca4000 - 0x7f75e5fa7fff  libm-2.17.so  ???
0x7f75e5fa8000 - 0x7f75e6296fff  libstdc++.so.6.0.18  ???  (WARNING: No symbols, libstdc++.so.6.0.18, 676136699F3BB3E58C19B83D8A296B660)
0x7f75e62ac000 - 0x7f75e64c4fff  libpthread-2.17.so  ???  (WARNING: No symbols, libpthread-2.17.so, 4CDAF5B4170C674F1A96E33F25274E0A0)
0x7f75e64c9000 - 0x7f75e6725fff  libGL.so.1.2.0  ???
0x7f75e6727000 - 0x7f75e69a4fff  libextension.so  ???  (WARNING: No symbols, libextension.so, 13E1DBC274C6099DEEF37259177DD16D0)
0x7f75e69a5000 - 0x7f75e6fa8fff  libcocos2d.so  ???
0x7f75e6fad000 - 0x7f75e6fcffff  ld-2.17.so  ???
0x7f75e6fde000 - 0x7f75e701ffff  libJsonCpp.so  ???
0x7f75e7021000 - 0x7f75e710efff  libEasySqlite.so  ???  (WARNING: No symbols, libEasySqlite.so, B4426B9A03AB419B458607C780DCCB1B0)
0x7f75e7142000 - 0x7f75e71ccfff  **libJansson.so**  ???  (**WARNING: No symbols**, libJansson.so, 31CEB5F4D63244C3BF657C501398D8650)

正如你所看到的，我没有 libJansson.so 的符号以及许多其他符号，这意味着在我的＆＃34;符号＆＃34;文件夹我需要有这个库的符号。

我可以用类似的方式生成它们

$google-breakpad/src/tools/linux/dump_syms/dump_syms ./libJansson.so > libJansson.so.sym
$head -n1 libJansson.so.sym

它会打印类似

的内容 
MODULE Linux x86_64 65C874A94F8B264EAE501D2694DFCBA60 libJansson.so

现在做出类似的事情：

$ mkdir -p ./symbols/libJansson.so/65C874A94F8B264EAE501D2694DFCBA60
$ mv test.sym ./symbols/libJansson.so/65C874A94F8B264EAE501D2694DFCBA60

现在我可以看到libJansson.so的堆栈跟踪

因此，如果你使用我的脚本，你必须只做这样的事情：

./script.py --dump_syms=/home/user/projects/libs/google-breakpad/src/tools/linux/dump_syms/dump_syms \
--minidump_stackwalk=/home/user/projects/libs/google-breakpad/src/processor/minidump_stackwalk \
--binary=./MyBinary --output_dir=/home/user/.config/MyBinary/dumps/ \
--dump_file=/home/user/.config/MyBinary/dumps/75ad100c-ef7c-c4eb-1da750f8-45586148.dmp

./script.py --dump_syms=/home/user/projects/libs/google-breakpad/src/tools/linux/dump_syms/dump_syms \
--minidump_stackwalk=/home/user/projects/libs/google-breakpad/src/processor/minidump_stackwalk \
--binary=./libJansson.so --output_dir=/home/user/.config/MyBinary/dumps/ \
--dump_file=/home/user/.config/MyBinary/dumps/75ad100c-ef7c-c4eb-1da750f8-45586148.dmp

答案 1 :(得分：1)

使用linux中的“minidump_stackwalk”来解析在windows上生成的'.sym'文件。但是，首先，您必须将'.sym'从dos格式转换为unix格式，将编码类型转换为UTF-8。 如果你跳过它，会出现上面提到的问题。

相关问题
最新问题