Most crash reports on 10.13 are missing system modules. The modules aren’t even listed in the minidump. That prevents them from being symbolized.
Example: go/crash/2b4b398bf0000000
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:
720 else if ( strcmp(segCmd->segname(), "__TEXT") == 0 ) {
721 // HACK until lldb fixed in: <rdar://problem/20357466> DynamicLoaderMacOSXDYLD fixes for Monarch dyld shared cache
722 segCmd->set_fileoff(0);
723
724 }
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.
Targeting to M60 for now. May want for M59 too, as this renders most crash reports difficult to work with.
Comment 1 by mark@chromium.org
, Jun 14 2017