我一直在使用google breakpad开发应用程序来生成故障转储，我注意到一旦应用程序被多线程化，就不会再生成崩溃转储（同时在.dmp文件中成功生成了.dmp文件）单线程应用程序）。
在搜索此问题的原因时，我发现an answered question while running under an i386 architecture我不认为与ARM问题超级相关，看起来是类似的 reported, but unresolved, issue with ARM.
在通常创建日志的回调函数中，给出了正确的路径，但是＆＃34;成功了＃34;布尔值是假的，我不确定我可以做什么，如果有的话，我可以做那个失败。
此应用程序在ARM Cortex-A9处理器上运行，如果有帮助的话。
我主要寻找任何类型的反馈或路径，我可以尝试解决此问题。如果我能提供任何进一步的信息，请告诉我。
答案 0 :(得分：0)
这是一个长镜头，但就我而言，问题是我正在使用-D_FILE_OFFSET_BITS=64编译我的应用程序（而不是breakpad）。这导致break_t中的breakpad为32位，但是我的应用程序认为它为64位。最终，对MinidumpDescriptor进行了操作，并将-1写入到其off_t字段（size_limit_）中，该字段溢出到相邻字段（skip_dump_if_principal_mapping_not_referenced_）中，将其设置为true（实际上，垃圾值大于0表示为true）。
如果人们愿意，我可以提供更多细节。我花了整整两天的时间来跟踪它，并希望节省其他人的麻烦。对我来说，解决方案是使用-D_FILE_OFFSET_BITS=64