使用线程时Breakpad无法在目标上创建minidump

本文介绍了使用线程时Breakpad无法在目标上创建minidump的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我发现使用线程时，测试应用程序无法生成正确的转储文件。我正在使用交叉编译器构建Breadpad库，然后将其与交叉编译器链接以在目标计算机上运行。

我将首先解释我的设置上：

构建于：Ubuntu 12.04，i686

主机/目标：Vortex86DX，它是i586 CPU，完全定制的Linux系统

构建工具：Buildroot，crosstool-ng，gcc 4.4.6，glibc 2.9

要构建Breakpad，我可以这样做：

$ ./configure CC = / opt / br / output / host / usr / bin / i486-unknown-linux-gnu-gcc CXX = / opt / br / output / host / usr / bin / i486-unknown-linux-gnu-g ++ --host = i486-unknown-linux-gnu $ make

我的交叉编译器已集成到Buildroot中，我想构建在-host = i486-unknown-linux-gnu

我这样交叉编译测试应用程序：

$ / opt / br / output / host / usr / bin / i486-unknown-linux-gnu-g ++ -g mytest.cpp客户端/ linux / libbreakpad_client.a -I。 -lrt -lpthread -lboost_thread -o mytest

测试应用程序为：

#include< boost / thread / thread.hpp> #include ./client/linux/handler/exception_handler.h #include< unistd.h> 静态bole dumpCallback（const google_breakpad :: MinidumpDescriptor& md， void *上下文，布尔值成功） { printf（转储路径：％s＼ ＼n，md.path（））; 返还成功； } void crash1（） { volatile int * a =（int *）（NULL）; * a = 1; } void crash2（） { volatile int x，y; y = 0; x / = y; } void t1（） { sleep（1）; crash1（）; } void t2（） { while（1）sleep（10）; } int main（） { google_breakpad :: MinidumpDescriptor md（ / tmp）; google_breakpad :: ExceptionHandler eh（md，NULL，dumpCallback，NULL，true，-1）; //注释掉以在线程崩溃，主崩溃，具有非崩溃线程的主崩溃之间进行选择 boost :: thread thread1（t2）; sleep（1）; crash1（）; sleep（3）; 返回0; }

我只是在从main（）崩溃和从线程崩溃之间创建变体。

在交叉编译并在目标上运行我的应用程序时的观察结果：

（1）测试应用程序，没有线程，将在目标上创建正确的转储文件。 PASS

（2）测试应用程序带有崩溃的线程，它将在目标上创建非常小的错误的转储文件（大多数为零）。失败

（3）测试应用程序具有不会崩溃的线程和主崩溃的线程，将在目标上创建中等大小且错误的转储文件。失败

编辑：在情况（1）中，回调返回successed = true。在情况（2）和（3）中，successed = false。因此，图书馆知道它没有成功。我想这是找出目标失败的原因，这是我的工作。

如果我编译同一测试应用程序以在构建计算机上运行，​​它将运行并创建正确的在所有情况下都转储文件。即我已经在我的构建计算机上成功运行了交叉编译的Crashpad库，它可以正常工作。由于build和host均为x86，所以这是可能的。

例如我使用非交叉编译g ++

g ++ -g mytest.cpp client / linux / libbreakpad_client.a -I进行构建。 -lrt -lpthread -lboost_thread -o mytest

我的问题是：

• 是Breakpad的问题？

• 我的交叉编译库是否有问题？

• 内核是否有所作为？我需要启用任何特定功能吗？

• 如何使其工作？即在我的目标上运行的多线程应用程序会生成正确的minidump文件

解决方案

Google Breakpad将无法在奔腾III之前的x86处理器上创建小型转储。

奔腾III及更高版本包含8个额外的浮点寄存器，这是请求的

src / client / linux / minidump_writer / linux_ptrace_dumper.cc： if（sys_ptrace（ PTRACE_GETFPXREGS，tid，NULL，& info-> fpxregs）== -1）返回false;

在奔腾III之前的处理器上，此调用将失败，从而导致整个minidump失败。 / p>

I've found that my test application does not generate a correct dump file when I use threads. I am using a cross-compiler to build the Breadpad library which is then linked with my cross-compiler to run on the target.

I'll start by explaining my set up:

Building on: Ubuntu 12.04, i686

Host/Target: Vortex86DX which is an i586 cpu, fully custom Linux system

Build tools: Buildroot, crosstool-ng, gcc 4.4.6, glibc 2.9

To build Breakpad I do this:

$ ./configure CC=/opt/br/output/host/usr/bin/i486-unknown-linux-gnu-gcc CXX=/opt/br/output/host/usr/bin/i486-unknown-linux-gnu-g++ --host=i486-unknown-linux-gnu $ make

My cross-compiler is integrated into Buildroot, and I want to build binaries that run on --host=i486-unknown-linux-gnu

I cross-compile my test app like so:

$ /opt/br/output/host/usr/bin/i486-unknown-linux-gnu-g++ -g mytest.cpp client/linux/libbreakpad_client.a -I. -lrt -lpthread -lboost_thread -o mytest

The test app is:

#include <boost/thread/thread.hpp> #include "./client/linux/handler/exception_handler.h" #include <unistd.h> static bool dumpCallback( const google_breakpad::MinidumpDescriptor &md, void *context, bool succeeded) { printf( "dump path: %s\n", md.path()); return succeeded; } void crash1() { volatile int* a = (int*)(NULL); *a = 1; } void crash2() { volatile int x, y; y = 0; x/=y; } void t1() { sleep(1); crash1(); } void t2() { while(1) sleep(10); } int main() { google_breakpad::MinidumpDescriptor md("/tmp"); google_breakpad::ExceptionHandler eh(md, NULL, dumpCallback, NULL, true, -1); // comment out to select between thread crash, main crash, main crash with non-crashing thread boost::thread thread1(t2); sleep(1); crash1(); sleep(3); return 0; }

I simply create variations between crashing from main() and crashing from a thread.

Observations when I cross compile and run my app on the target:

(1) the test app, with no threads, will create a correct dump file on the target. PASS

(2) the test app, with a thread that crashes, will create a very small and incorrect dump file (mostly zeroes) on the target. FAIL

(3) the test app, with a thread that doesn't crash, and a main that crashes, will create a medium sized and incorrect dump file on the target. FAIL

EDIT: In case (1), the callback returns succeeded=true. In cases (2) and (3), succeeded=false. So the library knows that it did not succeed. I guess it's my job to find out why it fails on my target.

If I compile the same test app to run on my build computer, it runs and creates a correct dump file in all circumstances. i.e. I have successfully run the cross-compiled Crashpad library on my build computer and it works as it should. Since both build and host are x86, this is possible.

e.g. I build using the non cross compile g++

g++ -g mytest.cpp client/linux/libbreakpad_client.a -I. -lrt -lpthread -lboost_thread -o mytest

My questions are:

• is the problem with Breakpad?

• is the problem with my cross compilation libraries?

• does the kernel make a difference? Do I need to enable any particular functionality?

• how can this be made to work? i.e. a multi-threaded app, running on my target, produces a correct minidump file

解决方案

Google Breakpad will fail to create a minidump on a pre-Pentium III x86 processor.

Pentium III and above contain 8 extra floating point registers that are requested by a sys_ptrace call in Breakpad.

src/client/linux/minidump_writer/linux_ptrace_dumper.cc: if (sys_ptrace(PTRACE_GETFPXREGS, tid, NULL, &info->fpxregs) == -1) return false;

On a pre-Pentium III processor this call will fail and this causes the entire minidump to fail.