Emit VMRegions for macOS when doing process memory dumps.

components/tracing/common/process_metrics_memory_dump_provider.cc

Index: components/tracing/common/process_metrics_memory_dump_provider.cc
diff --git a/components/tracing/common/process_metrics_memory_dump_provider.cc b/components/tracing/common/process_metrics_memory_dump_provider.cc
index 593755bada11899c83bd93f32689d819cd09fae7..5a5d16d4cbb51952f1959f4fe3f144ebef53618a 100644
--- a/components/tracing/common/process_metrics_memory_dump_provider.cc
+++ b/components/tracing/common/process_metrics_memory_dump_provider.cc
@@ -24,6 +24,14 @@
 #include "base/trace_event/process_memory_totals.h"
 #include "build/build_config.h"
 
+#if defined(OS_MACOSX)
+#include <mach/mach.h>
+#include <mach-o/loader.h>
+#include <mach-o/dyld_images.h>
+
+#include "base/mac/mach_logging.h"
+#endif  // defined(OS_MACOSX)
+
 namespace tracing {
 
 namespace {
@@ -219,6 +227,73 @@ bool ProcessMetricsMemoryDumpProvider::DumpProcessMemoryMaps(
 }
 #endif  // defined(OS_LINUX) || defined(OS_ANDROID)
 
+#if defined(OS_MACOSX)
+bool ProcessMetricsMemoryDumpProvider::DumpProcessMemoryMaps(
+    const base::trace_event::MemoryDumpArgs& args,
+    base::trace_event::ProcessMemoryDump* pmd) {
+  using VMRegion = base::trace_event::ProcessMemoryMaps::VMRegion;
+  task_dyld_info_data_t dyld_info;
+  mach_msg_type_number_t count = TASK_DYLD_INFO_COUNT;
+  kern_return_t kr =
+      task_info(mach_task_self(), TASK_DYLD_INFO,
+                reinterpret_cast<task_info_t>(&dyld_info), &count);
+  if (kr != KERN_SUCCESS) {
+    MACH_LOG(WARNING, kr) << "task_info";
+    return false;
+  }
+
+  const struct dyld_all_image_infos* all_image_infos =
+      reinterpret_cast<const struct dyld_all_image_infos*>(
+          dyld_info.all_image_info_addr);
+
+  for (size_t i = 0; i < all_image_infos->infoArrayCount; i++) {
+    const char* image_name = all_image_infos->infoArray[i].imageFilePath;
+
+    // The public definition for dyld_all_image_infos/dyld_image_info is wrong
+    // for 64-bit platforms. We explicitly cast to struct mach_header_64 even
+    // though the public definition claims that this is a struct mach_header.
+    const struct mach_header_64* const header =
+        reinterpret_cast<const struct mach_header_64* const>(
+            all_image_infos->infoArray[i].imageLoadAddress);
+
+    const struct load_command* load_cmd =
+        reinterpret_cast<const struct load_command*>(header + 1);
+    VMRegion region;
+    for (unsigned int i = 0; load_cmd && (i < header->ncmds); ++i) {
+      if (load_cmd->cmd == LC_SEGMENT_64) {
+        const segment_command_64* seg =
+            reinterpret_cast<const segment_command_64*>(load_cmd);
+
+        if (!strcmp(seg->segname, "__TEXT")) {

[Mark Mentovai, 2017/01/03 20:07:46]

You can use SEG_TEXT as a symbolic name for __TEXT. Also, I like to strcmp == 0
instead of !strcmp.

+          region.size_in_bytes = seg->vmsize;
+
+          // It's not clear what "protection_flags" means for an entire

[Mark Mentovai, 2017/01/03 20:07:46]

They’re the access bits set when the region is initially mapped. Sure, you can
change those bits up to what’s allowed by maxprot (or remap new pages in their
place even beyond maxprot), but all you’re seeing here is the mapped Mach-O
image. These bits that you’re looking at are just what the kernel or dyld use to
set the region’s initial prot and maxprot.

+          // VMRegion, since pages can have their own protection flags.
+          // segment_command_64 exposes "initprot" and "maxprot". We use
+          // "maxprot".
+          if (seg->maxprot & VM_PROT_READ)
+            region.protection_flags |= VMRegion::kProtectionFlagsRead;
+          if (seg->maxprot & VM_PROT_WRITE)
+            region.protection_flags |= VMRegion::kProtectionFlagsWrite;
+          if (seg->maxprot & VM_PROT_EXECUTE)
+            region.protection_flags |= VMRegion::kProtectionFlagsExec;
+          break;
+        }
+      }
+
+      load_cmd = reinterpret_cast<const struct load_command*>(
+          reinterpret_cast<const char*>(load_cmd) + load_cmd->cmdsize);

[Mark Mentovai, 2017/01/03 20:07:46]

Avoid running beyond header->sizeofcmds, bearing in mind that the entire segment
command that you interpret needs to fit within sizeofcmds.

+    }
+
+    region.mapped_file = image_name;
+    region.start_address = reinterpret_cast<uint64_t>(header);

[Mark Mentovai, 2017/01/03 20:07:46]

For this to be valid, __TEXT needs to be at offset 0, which it normally should
be. Check on seg->fileoff. Refer to
https://chromium.googlesource.com/crashpad/crashpad/+/bb7d249d65a1edd965499b7....

+    pmd->process_mmaps()->AddVMRegion(region);
+  }
+  pmd->set_has_process_mmaps();

[Mark Mentovai, 2017/01/03 20:07:46]

This only gets things that dyld knows about, including the main executable, but
excluding dyld itself. You can add dyld fairly easily, but even so, this is
somewhat short of everything that might be mapped. You can mmap() your own file
and this list won’t contain it, for example.

For that matter, you’re only looking at __TEXT, although almost every module
will have more than just that segment mapped. Even if just looking at the dyld
interface, you can add a new region (from this component’s perspective) for each
segment in a mapped Mach-O image.

The alternative would grab everything that’s been mapped, which is more like
what vmmap would tell you.

That may be more in line with what’s needed. The Linux implementation above
snarfs smaps, which is going to see everything that’s been mapped. But on the
other hand, Linux has no (standard) way to grab just the code modules that its
loader knows about, where macOS provides this dyld API that you’re using. How is
this code used? Should we grab all loaded modules, or just loaded code that the
loader’s aware of?

You can grab all mapped regions by walking the process’ VM map with Mach calls
(mach_vm_region_recurse()), and with each region, determine if it’s mapped by
calling proc_pidinfo() to fetch PROC_PIDREGIONPATHINFO and perhaps
PROC_PIDREGIONINFO. (If you only need PROC_PIDREGIONPATHINFO, try the
proc_regionfilename() wrapper.)

[Primiano Tucci (use gerrit), 2017/01/06 10:43:44]

On Linux/Android we deliberately decided to grab all mappings (not just code) as
the purpose of this is to debug the state of memory giving a snapshot of what
the OS sees.
Historically this helped us to pinpoint regressions of the form:
- Oh look there are some extra .ttf files mapped, this regression has something
to do with fonts. 
- Oh look there are a bunch of anonymous regions of size 512*512*4, these are
very likely some cc tiles.

Not sure how complicated and invasive would be doing the same on MacOS. If
possible would be desirable

+  return true;
+}
+#endif  // defined(OS_MACOSX)
+
 // static
 void ProcessMetricsMemoryDumpProvider::RegisterForProcess(
     base::ProcessId process) {
@@ -267,11 +342,11 @@ bool ProcessMetricsMemoryDumpProvider::OnMemoryDump(
     base::trace_event::ProcessMemoryDump* pmd) {
   bool res = DumpProcessTotals(args, pmd);
 
-#if defined(OS_LINUX) || defined(OS_ANDROID)
+#if defined(OS_LINUX) || defined(OS_ANDROID) || defined(OS_MACOSX)
   if (args.level_of_detail ==
       base::trace_event::MemoryDumpLevelOfDetail::DETAILED)
     res &= DumpProcessMemoryMaps(args, pmd);
-#endif
+#endif  // defined(OS_LINUX) || defined(OS_ANDROID) || defined(OS_MACOSX)
   return res;
 }