Got one more on 10.9, go/crash/45526f1e80000000, and one on 10.10, go/crash/0dd6ad0350000000.

Since these continue to trickle in and we didn’t see it at all until 60.0.3073.0, I’m beginning to get concerned that there may have been a regression in PersistentMemoryAllocator.

The last change to the PMA was on March 16th which added an internal "state" value, and a flush() method called it after initialization to ensure that state value was written to disk asap.

Line 344 is the first actual access to the shared memory segment so it looks like the mapping done by the MemoryMappedFile is invalid.

Would this crash be the same as SIGBUS?  That occurs when the OS in unable to map a page from the file into memory and can occur because of a disk i/o error or because the disk is full and a new page is unable to be added to the file.  But my understanding of Mac is that it doesn't support sparse files and thus the file is always pre-allocated on disk and this last item can't occur.

For more info on the general SIGBUS thing:

https://bugs.chromium.org/p/chromium/issues/detail?id=715523

https://docs.google.com/a/chromium.org/document/d/1pn_xc9JnSVUReIMM2awkMtBVkEFy1NjHCxzi3dq3D2g/edit?usp=sharing

EXC_BAD_ACCESS/KERN_MEMORY_ERROR would map to SIGBUS. This is in fact the exception and signal that you’d see if there’s no disk block backing mmap()ed region. For example:

  int fd = open("f", O_RDWR | O_CREAT | O_TRUNC, 0644);  // empty file
  char* p = (char*)mmap(NULL, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
  p[0] = 0;

The Mac kernel and its interfaces support sparse files, but the native filesystem, HFS+, doesn’t.

Ah, but there isn’t sufficient error handling! MemoryMappedFile::MapFileRegionToMemory() for READ_WRITE_EXTEND, as used by GlobalHistogramAllocator::CreateWithFile() when creating a new file, ignores the return value from File::SetLength(). The ftruncate() may in fact be failing with ENOSPC on macOS, but MemoryMappedFile would never catch that error. GlobalHistogramAllocator::CreateWithFile(), for that matter, wouldn’t catch the error coming back from MemoryMappedFile::Initialize() either.

Now it’s clear that it’s possible even on macOS for a disk-full situation to result in this EXC_BAD_ACCESS/KERN_MEMORY_ERROR (SIGBUS) crash.

This crash occurs in Chrome too. go/crash/6830319350000000.

https://codereview.chromium.org/2860943005/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e41b5ce8a877875575ad0c370bd4bdc8593113b2

commit e41b5ce8a877875575ad0c370bd4bdc8593113b2
Author: bcwhite <bcwhite@chromium.org>
Date: Thu May 11 20:27:50 2017

Ensure that memory-maped files are fully realized.

Memory-mapped files cause crashes if there are I/O problems. By ensuring
that the file is fully realized on disk, we eliminate a disk-full condition
from causing a crash down the road.

BUG=715523,  717331 

Review-Url: https://codereview.chromium.org/2860943005
Cr-Commit-Position: refs/heads/master@{#471056}

[modify] https://crrev.com/e41b5ce8a877875575ad0c370bd4bdc8593113b2/base/files/memory_mapped_file_posix.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f838936df9cdc2d95d64fb7cbae76a6ecd927cdd

commit f838936df9cdc2d95d64fb7cbae76a6ecd927cdd
Author: bcwhite <bcwhite@chromium.org>
Date: Thu Jun 15 15:51:35 2017

Don't realize existing parts of an extended memory-mapped file.

Realizing the entire file when extending a file is expensive and
unnecessary if we assume that the existing file is not sparse.  Just
realize the extension.

This is important for persistent metrics which creates a "spare" file
for use by the next run of the browser.  To realize it again would
negate most of the benefit of creating it in the first place.

BUG= 717331 

Review-Url: https://codereview.chromium.org/2939073002
Cr-Commit-Position: refs/heads/master@{#479718}

[modify] https://crrev.com/f838936df9cdc2d95d64fb7cbae76a6ecd927cdd/base/files/memory_mapped_file.cc
[modify] https://crrev.com/f838936df9cdc2d95d64fb7cbae76a6ecd927cdd/base/files/memory_mapped_file_posix.cc

There are no crash observed since : 61.0.3131.0, hence adding TE-Verified labels.

Link to the list of builds:
============================
https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Mac%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27base%3A%3APersistentMemoryAllocator%3A%3APersistentMemoryAllocator%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productversion:1000

Thank You...