mirror of
https://github.com/chromium/crashpad.git
synced 2024-12-30 01:06:56 +08:00
890ad441b3
In 10.13, modules loaded from the dyld shared cache appear with __TEXT segments that have a nonzero “fileoff” (file offset). Previously, the fileoff was always 0. Previously, the fileoff for segments in the dyld shared cache was the actual offset into the shared cache (not 0), but special consideration was given to __TEXT segments which were forced to 0. See 10.12.4 dyld-433.5/interlinked-dylibs/OptimizerLinkedit.cpp LinkeditOptimizer<>::updateLoadCommands(). Note the comment there where the __TEXT segment’s apparent fileoff is set to 0: // HACK until lldb fixed in: <rdar://problem/20357466> // DynamicLoaderMacOSXDYLD fixes for Monarch dyld shared cache Refer also to the lldb commit that references the above, http://llvm.org/viewvc/llvm-project?view=revision&revision=233714. Evidently, update_dyld_shared_cache has been revised to no longer apply this hack in 10.13. Crashpad’s sanity check for __TEXT segments having a fileoff of 0 is no longer valid, and causes it to reject modules loaded from the dyld shared cache. Since this was just a sanity check, remove it entirely. This caused module information for modules loaded from the dyld shared cache to be missing from minidumps produced on 10.13, which in turn prevented symbolization in frames belonging to most system libraries. For reasons not yet understood, I don’t see this problem in Chrome on 10.13db1 17A264c on a test virtual machine (HFS+ filesystem), although I do see it on actual hardware (APFS filesystem), and I do see it in Crashpad’s tests and reduced testcases on both as well. Bug: crashpad:185, crashpad:189 Test: crashpad_snapshot_test MachOImageReader.Self_DyldImages:ProcessReader.SelfModules:ProcessReader.ChildModules:ProcessTypes.DyldImagesSelf Change-Id: I8b0a22c55c33ce920804a879f6fab67272f3556e Reviewed-on: https://chromium-review.googlesource.com/535576 Reviewed-by: Robert Sesek <rsesek@chromium.org>