1

I've been developing an application using google breakpad for generating crash dumps, and I have noticed that once the application was multithreaded, crash dumps no longer appear to be generated (while a .dmp file was generated successfully in a single-threaded application).

In searching for the cause of this issue, I found an answered question while running under an i386 architecture which I do not believe is super relevant for the ARM issue, and what appears to be a similar reported, but unresolved, issue with ARM.

Within the callback function that normally creates the log, there is a correct path given, but the "succeeded" boolean is false, and I'm not certain what, if anything, I can do with that failure.

This application is running on an ARM Cortex-A9 processor, if that's helpful.

I'm primarily looking for any kind of feedback or paths I could go down to try and resolve this. Let me know if there is any further information I could provide.

Stump
  • 11
  • 3

1 Answers1

0

This is a long-shot, but in my case, the problem was I was compiling my application (but not breakpad) with -D_FILE_OFFSET_BITS=64. This resulted in off_t in breakpad being 32 bits, but my application thinking it was 64 bits. Eventually, a MinidumpDescriptor is manipulated and -1 is written to a off_t field of it (size_limit_), which spills into a neighboring field (skip_dump_if_principal_mapping_not_referenced_) setting it to true (actually, a garbage value greater than 0 that evaluates to true).

I can give more detail if people want. I spent two whole days tracking it down, and want to save someone else the trouble. The solution for me was to recompile breakpad with -D_FILE_OFFSET_BITS=64

Chris Laplante
  • 29,338
  • 17
  • 103
  • 134