zeeker999 / google-breakpad

Automatically exported from code.google.com/p/google-breakpad
0 stars 0 forks source link

Breakpad fails to create minidump on ARM when i use threads #653

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.
Cross-compile breakpad client for ARM with Codesourcery 2013.05, Host: Ubuntu 
12.04

Cross-compile using following commands:
export 
CC=/opt/CodeSourcery/Sourcery_G++_arm-2013.05/bin/arm-none-linux-gnueabi-gcc
export 
CXX=/opt/CodeSourcery/Sourcery_G++_arm-2013.05/bin/arm-none-linux-gnueabi-g++
./configure --host=arm-none-linux-gnueabi --disable-processor --disable-tools
make

2.
Follow example under:
https://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide
Everything works fine, minidump created and analyzed correctly by 
minidump_stackwalk.

3.
Extend main with a thread:

#include <cstdlib>
#include "client/linux/handler/exception_handler.h"
#include <pthread.h>

using namespace std;

static bool dumpCallback(const google_breakpad::MinidumpDescriptor& descriptor,
void* context,
bool succeeded)
{
   printf("Application crashed, dump path: %s, succeeded: %d\n", descriptor.path(), succeeded);
   return succeeded;
}

void thisWillcrash()
{
   volatile int* a = (int*)(NULL);
   *a = 1;
}

void* t2(void* ptr)
{
    while (1) sleep(10);
}

int main(int argc, char** argv)
{
  google_breakpad::MinidumpDescriptor descriptor("/tmp");
  google_breakpad::ExceptionHandler eh(descriptor,
                                       NULL,
                                       dumpCallback,
                                       NULL,
                                       true,
                                       -1);

  pthread_t thread1;
  pthread_create(&thread1, NULL, t2, NULL);

  thisWillcrash();

  pthread_join(thread1, NULL);
  return 0;
}

What is the expected output? What do you see instead?
I expect minidump_stackwalk still being able to analyze the created minidump.
Instead, the minidump is sensibly smaller (5kB instead of 12.2kB) and 
minidump_stackwalk fails:

2015-05-19 08:56:44: minidump.cc:4035: INFO: Minidump opened minidump 
dump/76231459-1807-478c-405757c3-6f18643e.dmp
2015-05-19 08:56:44: minidump.cc:4152: INFO: Minidump not byte-swapping minidump
2015-05-19 08:56:44: minidump.cc:4598: INFO: GetStream: type 15 not present
2015-05-19 08:56:44: minidump.cc:4598: INFO: GetStream: type 7 not present
2015-05-19 08:56:44: minidump.cc:4598: INFO: GetStream: type 7 not present
2015-05-19 08:56:44: minidump.cc:4598: INFO: GetStream: type 1197932545 not 
present
2015-05-19 08:56:44: minidump.cc:4598: INFO: GetStream: type 6 not present
2015-05-19 08:56:44: minidump.cc:4598: INFO: GetStream: type 1197932546 not 
present
2015-05-19 08:56:44: minidump.cc:4598: INFO: GetStream: type 4 not present
2015-05-19 08:56:44: minidump.cc:4598: INFO: GetStream: type 5 not present
2015-05-19 08:56:44: minidump.cc:4598: INFO: GetStream: type 3 not present
2015-05-19 08:56:44: minidump_processor.cc:137: ERROR: Minidump 
dump/76231459-1807-478c-405757c3-6f18643e.dmp has no thread list
2015-05-19 08:56:44: minidump_stackwalk.cc:93: ERROR: 
MinidumpProcessor::Process failed
2015-05-19 08:56:44: minidump.cc:4007: INFO: Minidump closing minidump

What version of the product are you using? On what operating system?
Revision 1456, checked out from trunk on mai 18, 2015.
Host OS: Ubuntu 12.04
Target OS: Linux 2.6.32 on armv7

Please provide any additional information below.

Original issue reported on code.google.com by um7...@gmail.com on 19 May 2015 at 7:11

GoogleCodeExporter commented 9 years ago
succeeded argument in dumpCallback() is false when using threads, otherwise 
(initial example) it's true.

Original comment by um7...@gmail.com on 19 May 2015 at 7:23

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
the unit tests are also failing on an arm build 
https://travis-ci.org/bor-sh-infrastructure/arm_buid_try/builds/73603721

Original comment by borshhs...@gmail.com on 3 Aug 2015 at 7:11

Attachments: