分析崩溃使用minidumps和GDB的mingw编译的可执行文件？ [英] Analyze crash using minidumps and GDB for mingw compiled executables?
问题描述
我使用Cmake + mingw编译我的项目。由于一些未知的时刻，我的程序开始崩溃在启动时，我想出了如何使Windows为我崩溃的应用程序使minidump。我会使用GDB直接调试我的应用程序，但当我使用GDB程序不会崩溃。
Google breakpad包含将minidumps转换为coredumps的工具，所以我试图编译google breakpad，但似乎breakpad不是windows解决方案。
我正在寻找解决方案如何检查minidump和找到为什么我的程序崩溃开始。
如何做？
I use Cmake + mingw to compile my project. Since some unknown moment my program started to crash on startup and i figured out how to make windows make minidump for my crashing application. I would use GDB to directly debug my application, but when i use GDB the program doesn't crash. Google breakpad contain tool to convert minidumps to coredumps, so i tryed to compile google breakpad but it seems breakpad is not windows solution. I'm searching for solution how to inspect minidump and find why my program crashes on start. How do you do it?
推荐答案
您不需要分析minidumps。相反，您可以将您的调试器设置为事后调试器。我在互联网上搜索用gdb替换postmortem调试器。看看，Mingw博士： https://github.com/jrfonseca/drmingw 。这是来自他们的网站：
You don't need to analyze minidumps. Instead you can set your debugger as a postmortem debugger. I have searched on the Internet for "windows replace postmortem debugger with gdb". Look, there is Dr. Mingw: https://github.com/jrfonseca/drmingw . This is from their site:
Mingw是一个即时（JIT）调试器。当应用程序
抛出一个未处理的异常，称为Mingw博士自身附加到
应用，并使用
提供的调试信息收集异常信息。
Dr. Mingw is a Just-in-Time (JIT) debugger. When the application throws an unhandled exception, Dr. Mingw attaches itself to the application and collects information about the exception, using the available debugging information.
我写了一个简单的C ++测试：
I have writen a simple C++ test:
int f()
{
int *ptr = 0;
*ptr = *ptr +1;
return *ptr;
}
int main()
{
f();
return 0;
}
建立：
g++ -g main.cpp
这是DrMingw的输出，当我的程序崩溃，并有您的磁盘上的源文件。您可以看到，很容易找到有问题的行：
This is the output of DrMingw when my program crashed and there are source files on your disk. As you can see it is quite easy to locate a line with a problem:
.exe caused an Access Violation at location 0040139C in module a.exe Reading from location 00000000.
Registers:
eax=00000000 ebx=7ffdb000 ecx=00000001 edx=77c51ae8 esi=01cedca2 edi=2eafc26a
eip=0040139c esp=0022ff38 ebp=0022ff48 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
AddrPC Params
0040139C 0000001D 7FFDB000 0022FFA0 a.exe!f() [D:\src-c++\test.crasj/main.cpp @ 4]
...
{
int *ptr = 0;
> *ptr = *ptr +1;
return *ptr;
}
...
004013BD 00000001 003D3DC0 003D2C78 a.exe!main [D:\src-c++\test.crasj/main.cpp @ 11]
...
{
f();
> return 0;
}
...
004010B9 00000001 A9FF6D08 7C90E64E a.exe!__mingw_CRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c @ 244]
00401284 2EAFC26A 01CEDCA2 7FFDB000 a.exe!WinMainCRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c @ 274]
7C816D4F 0040126C 00000000 78746341 kernel32.dll!RegisterWaitForInputIdle
如果试验是建立与-g但availbale没有源文件，然后Dr.Mingw的输出看起来是这样的，它也很清楚在这行你的程序崩溃：
If the test is build with "-g" but there is no source files availbale then the output of Dr.Mingw looks like this and it is also clear on which line your program crashed:
a.exe caused an Access Violation at location 0040139C in module a.exe Reading from location 00000000.
Registers:
eax=00000000 ebx=7ffd7000 ecx=00000001 edx=77c51ae8 esi=01cedca8 edi=ef612c64
eip=0040139c esp=0022ff38 ebp=0022ff48 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
AddrPC Params
0040139C 0000001D 7FFD7000 0022FFA0 a.exe!f() [D:\src-c++\test.crasj/main.cpp @ 4]
004013BD 00000001 003D3D98 003D2C50 a.exe!main [D:\src-c++\test.crasj/main.cpp @ 11]
004010B9 00000001 F7114D08 7C90E64E a.exe!__mingw_CRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c @ 244]
00401284 EF612C64 01CEDCA8 7FFD7000 a.exe!WinMainCRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c @ 274]
7C816D4F 0040126C 00000000 78746341 kernel32.dll!RegisterWaitForInputIdle
如果测试是没有-g的构建， Dr.Mingw看起来像这样：
If the test is build without "-g" then the output of Dr.Mingw looks like this:
a.exe caused an Access Violation at location 0040139C in module a.exe Reading from location 00000000.
Registers:
eax=00000000 ebx=7ffdf000 ecx=00000001 edx=77c51ae8 esi=01cedca4 edi=79abd658
eip=0040139c esp=0022ff38 ebp=0022ff48 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
AddrPC Params
0040139C 0000001D 7FFDF000 0022FFA0 a.exe
004013BD 00000001 003D3DC0 003D2C78 a.exe
004010B9 00000001 A9D73D08 7C90E64E a.exe!__mingw_CRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c @ 244]
00401284 79ABD658 01CEDCA4 7FFDF000 a.exe!WinMainCRTStartup [C:\MinGW\msys\1.0\src\mingwrt/../mingw/crt1.c @ 274]
7C816D4F 0040126C 00000000 78746341 kernel32.dll!RegisterWaitForInputIdle
这篇关于分析崩溃使用minidumps和GDB的mingw编译的可执行文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
