Fix SysInfo::AmountOfVirtualMemory and PlatformSharedBuffer::Map().

The meaning of base::SysInfo::AmountOfVirtualMemory() isn't well-
specified (e.g. under Windows it returns the calling process' maximum
address-space size, while under POSIX it returns the maximum memory
available via brk()-based malloc()). Under Fuchsia the Virtual Memory
Address Range is practically unlimited, so rather than return the size
of e.g. the root VMAR object of the calling process, we just return
zero (meaning "unlimited").

PlatformSharedBuffer::Map() was previously DCHECK()ing that mapping the
underlying SharedMemory object succeeded, and then always returning
"success" to the caller. This is fixed so that callers, including the
Mojo PlatformSharedBufferTest.TooBig test, can handle the Map()
failure.

The PlatformSharedBuffer.TooBig test is fixed to actually attempt to
Create() a too-big shared buffer, rather than a zero-byte one, and the
test is removed from the Fuchsia test filters.

Bug: 740791, 706592
Change-Id: I76d3f1e4201c8cc6c143e469e5d1f081b359aa38
Reviewed-on: https://chromium-review.googlesource.com/620293
Commit-Queue: Wez <wez@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495459}

CrOS-Libchrome-Original-Commit: 8f8498b3987d2036fb8f7e578c1d24e4a046e163
3 files changed
tree: 022ce1a0849ce2ddee32a59053841029318f592e
  1. base/
  2. build/
  3. components/
  4. dbus/
  5. device/
  6. ipc/
  7. mojo/
  8. testing/
  9. third_party/
  10. ui/