This patch fixes the following error:
../../third_party/crashpad/crashpad/snapshot/linux/cpu_context_linux.cc:246:12: error: 'numeric_limits' is not a member of 'std'
std::numeric_limits<decltype(context->spsr)>::max()) {
^~~~~~~~~~~~~~
../../third_party/crashpad/crashpad/snapshot/linux/cpu_context_linux.cc:246:27: error: expected primary-expression before 'decltype'
std::numeric_limits<decltype(context->spsr)>::max()) {
^~~~~~~~
../../third_party/crashpad/crashpad/snapshot/linux/cpu_context_linux.cc:246:27: error: expected ')' before 'decltype'
Bug: chromium:819294
Change-Id: I4f31a33fcdae9567c71a4d371d2e6afe68d2ef6a
Reviewed-on: https://chromium-review.googlesource.com/c/1454376
Commit-Queue: Maksim Sisov <msisov@igalia.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Fuchsia in the future will create VMOs as non-executable (i.e.,
without ZX_RIGHT_EXECUTE) by default, so this necessary preparation
for that.
Change-Id: I00ada804d1d16db4f50ff3882058e382b1845328
Reviewed-on: https://chromium-review.googlesource.com/c/1419778
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Matthew Dempsky <mdempsky@chromium.org>
Since gtest 00938b2b228f3, gtest has built-in first-class support for
skipping tests, which is functionally identical (at least in Crashpad’s
usage) to the home-grown support for run-time dynamically disabled tests
introduced in Crashpad 5e9ed4cb9f69.
Use the new standard pattern, and remove all vestiges of the custom
local one.
Change-Id: Ia332136c356d523885fc5d86bc8f06fefbe6a792
Reviewed-on: https://chromium-review.googlesource.com/c/1427242
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Use-after-return detection happens to currently be enabled on Linux and
Android but is not exclusive to those platforms. Disable tests
incompatible with ASan UAR detection on all platforms.
Bug: 915245
Change-Id: I40447c126dac9dc7d0f72e400136afb8c292324d
Reviewed-on: https://chromium-review.googlesource.com/c/1414614
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
These changes were made in the upstream version of crashpad without
being contributed back to crashpad.
Bug: crashpad:271
Change-Id: I60f6dfd206191e65bac41978a7c88d06b8c3cee9
Reviewed-on: https://chromium-review.googlesource.com/c/1389238
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Test: Existing
Change-Id: I36fde186de372d2b86807f4da4e6e589a1b19706
Reviewed-on: https://chromium-review.googlesource.com/c/1395479
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This is a follow-up to c8a016b99d97, following the post-landing
discussion at
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1393921/5#message-2058541d8c4505d20a990ab7734cd758e437a5f7
base::size, and std::size that will eventually replace it when C++17 is
assured, does not allow the size of non-static data members to be taken
in constant expression context. The remaining uses of ArraySize are in:
minidump/minidump_exception_writer.cc (×1)
minidump/minidump_system_info_writer.cc (×2, also uses base::size)
snapshot/cpu_context.cc (×4, also uses base::size)
util/misc/arraysize_test.cc (×10, of course)
The first of these occurs when initializing a constexpr variable. All
others are in expressions used with static_assert.
Includes:
Update mini_chromium to 737433ebade4d446643c6c07daae02a67e8deccao
f701716d9546 Add Windows ARM64 build target to mini_chromium
87a95a3d6ac2 Remove the arraysize macro
1f7255ead1f7 Placate MSVC in areas of base::size usage
737433ebade4 Add cast
Bug: chromium:837308
Change-Id: I6a5162654461b1bdd9b7b6864d0d71a734bcde19
Reviewed-on: https://chromium-review.googlesource.com/c/1396108
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
In preparation for deleting the custom CrashpadInfo reading routines in
the PEImageReader and also deleting the PEImageAnnotationsReader, this
change moves ModuleSnapshotWin to using the platform-independent
CrashpadInfoReader.
Bug: crashpad:270
Change-Id: Idad5de173200068243eacb2bb11b2d95b6438e90
Reviewed-on: https://chromium-review.googlesource.com/c/1388017
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This API was added for Kasko several years ago but that project is
defunct and this API does not appear to be used elsewhere.
Bug: crashpad:270
Change-Id: I5a409deff7c5cf4f9f552893d4a49303f3000164
Reviewed-on: https://chromium-review.googlesource.com/c/1388022
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
In preparation for deleting the PEImageAnnotationsReader (and replacing
it with the generic ImageAnnotationsReader) change the
PEImageAnnotationsReader test to be a ModuleSnapshotWin test instead.
The tests are still useful for testing the annotations on the module
snapshot.
Bug: crashpad:270
Change-Id: Ibbbc69c72ca2eb98bfae9dc9b57bf28e9d3f12e2
Reviewed-on: https://chromium-review.googlesource.com/c/1388018
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Plumb ProcessReaderMac::Memory() through to ProcessSnapshotMac::Memory()
and add consts where necessary to accomodate the type signature of
ProcessSnapshot::Memory().
Bug: crashpad:263
Change-Id: I2608979918bc201ae3561483ea52ed2092cbc1e2
Reviewed-on: https://chromium-review.googlesource.com/c/1387924
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Currently, TaskMemory implements the ProcessMemory interface almost
exactly; however, it's initialized using a constructor instead of an
Initialize method which makes it incompatible with a number of
ProcessMemory tests. Change its initialization to match the other
ProcessMemory classes.
Bug: crashpad:263
Change-Id: I8022dc3e1827a5bb398aace0058ce9494b6b6eb6
Reviewed-on: https://chromium-review.googlesource.com/c/1384447
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Add MemoryMap::Iterator to support different strategies for locating
the start of module mappings on Android and Linux.
Beginning with API 21, Bionic provides android_dlopen_ext() which
allows passing a file descriptor with an existing relro segment to the
loader. This means that the mapping containing the dynamic segment
could have a name, device, and inode which are different than the
other mappings for the module.
The revised strategy for Android at API 21+ is to search all mappings
in reverse order from they dynamic array mapping until a module is
parsed with the expected dynamic array address.
Linux and Android 20- continue to select mappings using the device,
inode, and file offsets of the mappings.
Bug: crashpad:268
Change-Id: I30e95e51cb6874c00875d2a9c57f1249877736d4
Reviewed-on: https://chromium-review.googlesource.com/c/1374375
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This plumbs some of the ZX_INFO_PROCESS_MAPS information out into
MINIDUMP_MEMORY_INFO. The mapping loses some information that Zircon
provides, and some of the data that Windows would provide isn't
available (for example, AllocationProtect). But this gives a general
idea of the memory layout of the process to check for bad pointers, etc.
when inspecting crashes.
Bug: fuchsia:DX-615
Change-Id: I2d7c02be0996672253cf0b1eb6a60b0a55e6033b
Reviewed-on: https://chromium-review.googlesource.com/c/1377089
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
we now run this code on arm64 devices in debug mode
Bug: crashpad:196
Bug: fuchsia:DX-712
Change-Id: Iea1975c5bd4cab3d503ca371ab731e25962fb255
Tested: /system/test/crashpad_tests on arm64 device in debug mode
Reviewed-on: https://chromium-review.googlesource.com/c/1352097
Commit-Queue: Francois Rousseau <frousseau@google.com>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Add const to ProcessMemory pointers from ProcessReaderLinux::Memory().
This code is ifdef'd to only build on ARM/MIPS.
Change-Id: I93983a83d06bd5bd338b93babdb326fa94925c53
Reviewed-on: https://chromium-review.googlesource.com/c/1341228
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Add a method to ProcessSnapshotMinidump to expose a similar interface
to ModuleSnapshot::CustomMinidumpStreams(). It's implemented on the
process snapshot here because there is no way to map custom minidump
streams back to a specific module. This allows implementing tests that
inspect custom user streams in minidumps.
Bug: 896019
Change-Id: I1673c342753e13d64bddcc0083ca29fa356deac7
Reviewed-on: https://chromium-review.googlesource.com/c/1271405
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Add a method to the ProcessSnapshot to expose a ProcessMemory object to
allow reading memory directly from the underlying process.
CQ-DEPEND=CL:1278830
BUG=crashpad:262
Change-Id: Ied2a5510a9b051c7ac8c41cdd060e8daa531086e
Reviewed-on: https://chromium-review.googlesource.com/c/1315428
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Remove ProcessReaderWin's ReadMemory() and ReadAvailableMemory() methods
and replace their uses with a new method that exposes an instance of
ProcessMemoryWin instead.
BUG=crashpad:262
Change-Id: Ief5b660b0504d7a740ee53c7cd2fa7672ae56249
Reviewed-on: https://chromium-review.googlesource.com/c/1278830
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Flaking like:
[ RUN ] ProcessReaderFuchsia.ChildThreads
[22244:22258:20181109,001621.809627:ERROR scoped_task_suspend.cc:44] thread failed to suspend
[22244:22258:20181109,001621.810893:WARNING process_reader_fuchsia.cc:283] zx_thread_read_state(ZX_THREAD_STATE_GENERAL_REGS): ZX_ERR_BAD_STATE (-20)
[22244:22258:20181109,001621.810937:WARNING process_reader_fuchsia.cc:295] zx_thread_read_state(ZX_THREAD_STATE_VECTOR_REGS): ZX_ERR_BAD_STATE (-20)
../../third_party/crashpad/snapshot/fuchsia/process_reader_fuchsia_test.cc:161: Failure
Expected: (threads[i].stack_regions.size()) > (0u), actual: 0 vs 0
[ FAILED ] ProcessReaderFuchsia.ChildThreads (2487 ms)
ScopedTaskSuspend appears to try relatively hard to suspend, and without
retrying indefinitely it's not clear how to do a better job. Retrying
forever isn't suitable for production code though, where it would cause
the crash reporter to hang.
Bug: fuchsia:US-553
Change-Id: Ie233d2f5578cb8c35ce47207df4f1f8d2e1152f1
Reviewed-on: https://chromium-review.googlesource.com/c/1328022
Reviewed-by: Francois Rousseau <frousseau@google.com>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This reverts commit 7f71c57a29cd9cfa719eb7730d8984aaef4adc05.
Reason for revert: Fuchsia has been transitioned to spsr.
Original change's description:
> [fuchsia] re-introduce pstate temporarily
>
> https://fuchsia.googlesource.com/garnet/+/master/bin/zxdb/client/minidump_remote_api.cc#127
> still depends on pstate and we cannot run CQ for hard transitions in Fuchsia yet
>
> Change-Id: Iea2bfc670871a8fe3f389cc54627733e6069ecbe
> Reviewed-on: https://chromium-review.googlesource.com/c/1318067
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Commit-Queue: Francois Rousseau <frousseau@google.com>
TBR=scottmg@chromium.org,frousseau@google.com
Change-Id: I5a13cab9a11b6c1262d6832e2dd5b09cad5b3740
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1321269
Reviewed-by: Francois Rousseau <frousseau@google.com>
Commit-Queue: Francois Rousseau <frousseau@google.com>
This is a reland of 95e97a32eba4d505ab9591e683d2147c441eea48
Original change's description:
> Use a relative address in .note.crashpad.info
>
> The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
> from desc.
>
> Making this note writable can trigger a linker error resulting in
> the binary embedding .note.crashpad.info to be rejected by the
> kernel during program loading.
>
> The error was observed with:
> GNU ld (GNU Binutils for Debian) 2.30
> clang version 4.0.1-10 (tags/RELEASE_401/final)
> Debian 4.17.17-1rodete2
>
> When the note is made writable, crashpad_snapshot_test contains two
> PT_LOAD segments which map to the same page.
>
> LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000258 0x0000000000000258 R 0x200000
> LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
> 0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
>
> Executing this binary with the execv system call triggers a segfault
> during program loading (an error can't be returned because the original
> process vm has already been discarded).
>
> I suspect (I haven't set up a debuggable kernel) the failure occurs
> while attempting to map the second load segment because its virtual
> address, 0x258, is in the same page as the first load segment.
> https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
>
> The linker normally produces consecutive load segments where the second
> segment is loaded 0x200000 bytes after the first, which I think is the
> maximum expected page size. Modifying the test executable to load the
> second segment at 0x1258 (4096 byte page size) allows program loading
> to succeed (but of course crashes after control is given to it).
>
> Bug: crashpad:260
> Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
> Reviewed-on: https://chromium-review.googlesource.com/c/1292232
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Bug: crashpad:260
Change-Id: I66713de84cc26c9119e0454d19c9c189263fe054
Reviewed-on: https://chromium-review.googlesource.com/c/1318066
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
pthread_threadid_np() reports an incorrect thread ID after fork() on
macOS 10.14 (“Mojave”). See https://openradar.appspot.com/43843552. As a
workaround, use thread_info(…, THREAD_IDENTIFIER_INFO, …).
This uses MachThreadSelf(), which in turn uses pthread_mach_thread_np(),
which does not suffer from the same bug. As an alternative,
base::mac::ScopedMachSendRight(mach_thread_self()) could be used.
Bug: crashpad:249
Change-Id: I757d6e94236cff533b9c1326f028110b6d214ee5
Reviewed-on: https://chromium-review.googlesource.com/c/1318271
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Bug: crashpad:264
Change-Id: Ie185fbe6fe909568b7364496586fb950c074674f
Reviewed-on: https://chromium-review.googlesource.com/c/1318378
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This reverts commit 95e97a32eba4d505ab9591e683d2147c441eea48.
Reason for revert: arm64 lto build
Original change's description:
> Use a relative address in .note.crashpad.info
>
> The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
> from desc.
>
> Making this note writable can trigger a linker error resulting in
> the binary embedding .note.crashpad.info to be rejected by the
> kernel during program loading.
>
> The error was observed with:
> GNU ld (GNU Binutils for Debian) 2.30
> clang version 4.0.1-10 (tags/RELEASE_401/final)
> Debian 4.17.17-1rodete2
>
> When the note is made writable, crashpad_snapshot_test contains two
> PT_LOAD segments which map to the same page.
>
> LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000258 0x0000000000000258 R 0x200000
> LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
> 0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
>
> Executing this binary with the execv system call triggers a segfault
> during program loading (an error can't be returned because the original
> process vm has already been discarded).
>
> I suspect (I haven't set up a debuggable kernel) the failure occurs
> while attempting to map the second load segment because its virtual
> address, 0x258, is in the same page as the first load segment.
> https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
>
> The linker normally produces consecutive load segments where the second
> segment is loaded 0x200000 bytes after the first, which I think is the
> maximum expected page size. Modifying the test executable to load the
> second segment at 0x1258 (4096 byte page size) allows program loading
> to succeed (but of course crashes after control is given to it).
>
> Bug: crashpad:260
> Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
> Reviewed-on: https://chromium-review.googlesource.com/c/1292232
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Joshua Peraza <jperaza@chromium.org>
TBR=scottmg@chromium.org,jperaza@chromium.org,mark@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: crashpad:260
Change-Id: I7a2c741e6b4c10d3e3b8be3213a8ce2cd93675f7
Reviewed-on: https://chromium-review.googlesource.com/c/1316372
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
dbghelp.h requires windows.h to have been included.
Change-Id: I66d40e396d60cafe99c2480fdfbf1a9114abe386
Reviewed-on: https://chromium-review.googlesource.com/c/1315787
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
from desc.
Making this note writable can trigger a linker error resulting in
the binary embedding .note.crashpad.info to be rejected by the
kernel during program loading.
The error was observed with:
GNU ld (GNU Binutils for Debian) 2.30
clang version 4.0.1-10 (tags/RELEASE_401/final)
Debian 4.17.17-1rodete2
When the note is made writable, crashpad_snapshot_test contains two
PT_LOAD segments which map to the same page.
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000258 0x0000000000000258 R 0x200000
LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
Executing this binary with the execv system call triggers a segfault
during program loading (an error can't be returned because the original
process vm has already been discarded).
I suspect (I haven't set up a debuggable kernel) the failure occurs
while attempting to map the second load segment because its virtual
address, 0x258, is in the same page as the first load segment.
https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
The linker normally produces consecutive load segments where the second
segment is loaded 0x200000 bytes after the first, which I think is the
maximum expected page size. Modifying the test executable to load the
second segment at 0x1258 (4096 byte page size) allows program loading
to succeed (but of course crashes after control is given to it).
Bug: crashpad:260
Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
Reviewed-on: https://chromium-review.googlesource.com/c/1292232
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
We also remove the NOTREACHED guard from ExtraMemory and just let it
return nothing (see comment for rationale). This should be the last of
the methods in ThreadSnapshotMinidump.
Bug: crashpad:10
Change-Id: If7148d3ead1ae5887da300131efc8a078b350b54
Reviewed-on: https://chromium-review.googlesource.com/c/1296806
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Casey Dahlin <sadmac@google.com>
Most of the methods are implemented now. Only a couple stragglers left.
Bug: crashpad:10
Change-Id: Ib0d2f7571d9a0e7bab1a24c66355c05804b63367
Reviewed-on: https://chromium-review.googlesource.com/c/1290171
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Casey Dahlin <sadmac@google.com>
We can now get the CPU state for threads from minidump snapshots.
Bug: crashpad:10
Change-Id: I6bef2b033f7b04fcfa64c114be94064f3e0ae775
Reviewed-on: https://chromium-review.googlesource.com/c/1285034
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Only partially implemented, but we can get most of the useful stuff,
including CPU Architecture.
Bug: crashpad:10
Change-Id: I727eeef5770430253a45cd046a66488f743ac25a
Reviewed-on: https://chromium-review.googlesource.com/c/1285033
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Only partially implemented, but ProcessSnapshotMinidump now returns them
appropriately.
Bug: crashpad:10
Change-Id: I44f598256965e404f62bd93e9e2efc61527298db
Reviewed-on: https://chromium-review.googlesource.com/c/1278280
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This warning triggers reliably on most binaries and on android, spams
the logcat which may obfuscate other errors.
The actual amount varies, but is typically 40 bytes for 32-bit android
system libraries, 80 bytes for 64-bit android system libraries,
64 bytes for linux system libraries (on my machine), but so far they're
all zeroes.
Change-Id: I658434e8290c75641a3b17034ebdd958834bcd69
Reviewed-on: https://chromium-review.googlesource.com/c/1269740
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Modules mapped from zipfiles will have mappings named for the zipfile
rather than the module name and an offset into that zipfile instead of
0.
Bug: crashpad:253, crashpad:254
Change-Id: I0503d13e7b80ba7bd1cc2d241633d9c68c98f1cd
Reviewed-on: https://chromium-review.googlesource.com/1232294
Reviewed-by: Mark Mentovai <mark@chromium.org>
SELinux blocks the handler from collecting these values on Android M.
They should eventually be collected via the broker.
Change-Id: Iad47759b2ebf23148cb5b2c401241ee87f8ffd27
Reviewed-on: https://chromium-review.googlesource.com/1226120
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
