我一直在开发一个使用 google breakpad 生成故障转储的应用程序，我注意到一旦应用程序是多线程的，似乎不再生成故障转储（而在单线程应用程序中成功生成了 .dmp 文件） .
在寻找此问题的原因时，我在 i386 架构下运行时发现了一个已回答的问题，我认为该问题与 ARM 问题无关，并且似乎 与 ARM 报告了类似但未解决的问题。
在通常创建日志的回调函数中，给出了正确的路径，但“成功”的布尔值是错误的，我不确定我能做什么，如果有的话，我可以用这个失败做什么。
此应用程序在 ARM Cortex-A9 处理器上运行，如果有帮助的话。
我主要是在寻找可以尝试解决此问题的任何类型的反馈或路径。如果我可以提供任何进一步的信息，请告诉我。
这是一个长镜头，但在我的情况下，问题是我正在编译我的应用程序（但不是 breakpad）-D_FILE_OFFSET_BITS=64。这导致 breakpad 中的 off_t 为 32 位，但我的应用程序认为它是 64 位。最终，一个 MinidumpDescriptor 被操作，并且 -1 被写入它的一个 off_t 字段 ( size_limit_)，它溢出到一个相邻的字段 ( skip_dump_if_principal_mapping_not_referenced_) 中，将其设置为 true （实际上，一个大于 0 的垃圾值评估为 true）。
如果人们愿意，我可以提供更多细节。我花了整整两天的时间来追踪它，并想为别人省去麻烦。我的解决方案是重新编译breakpad-D_FILE_OFFSET_BITS=64