Add crash keys about field trial shared memory errors.

Add crash keys about field trial shared memory errors.

This is needed to figure out the cause of the failures in field
trial shared memory allocation & map operations.

Adds crash keys for the error values when shared memory
APIs fail from field trial code, to diagnose the crash causes.

The temporary logging CL adds coverage to Mac codepaths
specifically, since that is the issue being investigated. The
plan is to clean up the code once the crbug has been fixed.

BUG=703649
Review-Url: https://codereview.chromium.org/2872503003
Cr-Commit-Position: refs/heads/master@{#470802}
Committed: https://chromium.googlesource.com/chromium/src/+/0fe371d918bf4d467619c1cd2d9fd9f3ee117add

[Alexei Svitkine (slow), 2017-05-08 21:10:26]

The CQ bit was checked by asvitkine@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-08 21:11:23]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Alexei Svitkine (slow), 2017-05-08 21:16:45]

Description was changed from

==========
Expose error information from shared memory APIs.

BUG=
==========

to

==========
Expose error information from shared memory APIs.

This is needed to figure out the cause of the failures in field trial shared
memory allocation & map operations.

BUG=703649
==========

[commit-bot: I haz the power, 2017-05-08 21:24:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-08 21:24:35]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[Alexei Svitkine (slow), 2017-05-08 21:50:52]

The CQ bit was checked by asvitkine@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-08 21:51:57]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-08 22:06:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-08 22:06:04]

Dry run: Try jobs failed on following builders:
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[Alexei Svitkine (slow), 2017-05-08 22:06:29]

Description was changed from

==========
Expose error information from shared memory APIs.

This is needed to figure out the cause of the failures in field trial shared
memory allocation & map operations.

BUG=703649
==========

to

==========
Expose error information from shared memory APIs.

This is needed to figure out the cause of the failures in field
trial shared memory allocation & map operations.

Adds crash keys for the error values when shared memory
APIs fail from field trial code, to diagnose the crash causes.

BUG=703649
==========

[Alexei Svitkine (slow), 2017-05-08 22:06:37]

The CQ bit was checked by asvitkine@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-08 22:07:55]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Alexei Svitkine (slow), 2017-05-08 22:10:11]

Patchset #3 (id:40001) has been deleted

[Alexei Svitkine (slow), 2017-05-08 22:10:17]

Patchset #3 (id:60001) has been deleted

[Alexei Svitkine (slow), 2017-05-08 22:10:28]

Patchset #1 (id:1) has been deleted

[commit-bot: I haz the power, 2017-05-08 22:47:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-08 22:47:18]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Alexei Svitkine (slow), 2017-05-09 15:24:06]

The CQ bit was checked by asvitkine@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-09 15:24:44]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Alexei Svitkine (slow), 2017-05-09 16:42:02]

Patchset #2 (id:80001) has been deleted

[Alexei Svitkine (slow), 2017-05-09 16:42:07]

Patchset #1 (id:20001) has been deleted

[commit-bot: I haz the power, 2017-05-09 17:05:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-09 17:05:37]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Alexei Svitkine (slow), 2017-05-09 18:10:42]

Description was changed from

==========
Expose error information from shared memory APIs.

This is needed to figure out the cause of the failures in field
trial shared memory allocation & map operations.

Adds crash keys for the error values when shared memory
APIs fail from field trial code, to diagnose the crash causes.

BUG=703649
==========

to

==========
Add crash keys about field trial shared memory errors.

This is needed to figure out the cause of the failures in field
trial shared memory allocation & map operations.

Adds crash keys for the error values when shared memory
APIs fail from field trial code, to diagnose the crash causes.

BUG=703649
==========

[Alexei Svitkine (slow), 2017-05-09 18:11:03]

asvitkine@chromium.org changed reviewers:
+ erikchen@chromium.org, thakis@chromium.org

[erikchen, 2017-05-09 18:23:31]

Some questions:

1) Is this intended to be temporary or permanent code? If temporary, please make
it very clear that you intend to remove all this code afterwards, with TODOs,
links to crbugs, and updated CL description. If permanent, please don't hack in
an implementation that only works for macOS POSIX, and please change the
Create() API to return an error.

2) I'm having trouble which platforms this code is intended to run on. It looks
like this is only plumbed through for macOS POSIX, but I also see changes to
*win files.

[Alexei Svitkine (slow), 2017-05-09 18:31:31]

For 1, wanted to hear your perspective on this, as I can go either way. We
could remove it post investigation or make it part of the API.

What do you think? With this CL, I was sort of thinking we can make that
decision when cleaning up the crash keys - i.e. to expand the error support
more at that time or to remove it.

For 2, the changes to chrome_crash_reporter_client_win.cc is for
consistency with crash_keys.cc - since there's two parallel lists that
should be maintained. While the linked bug is about Mac specifically, the
code path where CrashKeys are being added can be hit on Windows too, so the
crash keys should be defined in both places.

On Tue, May 9, 2017 at 2:23 PM, <erikchen@chromium.org> wrote:

> Some questions:
>
> 1) Is this intended to be temporary or permanent code? If temporary,
> please make
> it very clear that you intend to remove all this code afterwards, with
> TODOs,
> links to crbugs, and updated CL description. If permanent, please don't
> hack in
> an implementation that only works for macOS POSIX, and please change the
> Create() API to return an error.
>
> 2) I'm having trouble which platforms this code is intended to run on. It
> looks
> like this is only plumbed through for macOS POSIX, but I also see changes
> to
> *win files.
>
> https://codereview.chromium.org/2872503003/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alexei Svitkine (slow), 2017-05-10 14:42:23]

Okay, per the above reply I went and added TODOs to the error API I'm adding to
shared_memory.h to either remove it or expand it to all platforms once we fix
the linked bug. PTAL.

Would appreciate fast review iteration time here since the linked bug is marked
as a stable blocker for M60.

[Nico, 2017-05-10 15:12:22]

lgtm if Erik likes it.

https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
File base/memory/shared_memory.h (right):

https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
base/memory/shared_memory.h:289: SharedMemoryError last_error_ =
SharedMemoryError::NO_ERRORS;
nit: please init in ctor, like for all other members of this class

[Alexei Svitkine (slow), 2017-05-10 15:22:39]

https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
File base/memory/shared_memory.h (right):

https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
base/memory/shared_memory.h:289: SharedMemoryError last_error_ =
SharedMemoryError::NO_ERRORS;
On 2017/05/10 15:12:22, Nico wrote:
> nit: please init in ctor, like for all other members of this class

Unfortunately, it's not a single ctor - it's 7 different ones spread between
_mac.cc, _win.cc and _posix.cc. Seems like a lot of churn to add it to all of
them, especially if it ends up being temporary. So my preference would be to
keep as-is unless you have a really strong objection.

[Nico, 2017-05-10 15:36:18]

On Wed, May 10, 2017 at 11:22 AM, <asvitkine@chromium.org> wrote:

>
> https://codereview.chromium.org/2872503003/diff/120001/
> base/memory/shared_memory.h
> File base/memory/shared_memory.h (right):
>
> https://codereview.chromium.org/2872503003/diff/120001/
> base/memory/shared_memory.h#newcode289
> base/memory/shared_memory.h:289: SharedMemoryError last_error_ =
> SharedMemoryError::NO_ERRORS;
> On 2017/05/10 15:12:22, Nico wrote:
> > nit: please init in ctor, like for all other members of this class
>
> Unfortunately, it's not a single ctor - it's 7 different ones spread
> between _mac.cc, _win.cc and _posix.cc. Seems like a lot of churn to add
> it to all of them, especially if it ends up being temporary. So my
> preference would be to keep as-is unless you have a really strong
> objection.
>

I think it's extremely confusing if a class uses mixed style for this. I'm
also happy with a prerequisite CL that moves stuff out of the 7 ctors into
in-class initializers instead.

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alexei Svitkine (slow), 2017-05-10 15:39:51]

Fair enough. pre-CL sg - I'll prepare that.

On Wed, May 10, 2017 at 11:36 AM, Nico Weber <thakis@chromium.org> wrote:

> On Wed, May 10, 2017 at 11:22 AM, <asvitkine@chromium.org> wrote:
>
>>
>> https://codereview.chromium.org/2872503003/diff/120001/base/
>> memory/shared_memory.h
>> File base/memory/shared_memory.h (right):
>>
>> https://codereview.chromium.org/2872503003/diff/120001/base/
>> memory/shared_memory.h#newcode289
>> base/memory/shared_memory.h:289: SharedMemoryError last_error_ =
>> SharedMemoryError::NO_ERRORS;
>> On 2017/05/10 15:12:22, Nico wrote:
>> > nit: please init in ctor, like for all other members of this class
>>
>> Unfortunately, it's not a single ctor - it's 7 different ones spread
>> between _mac.cc, _win.cc and _posix.cc. Seems like a lot of churn to add
>> it to all of them, especially if it ends up being temporary. So my
>> preference would be to keep as-is unless you have a really strong
>> objection.
>>
>
> I think it's extremely confusing if a class uses mixed style for this. I'm
> also happy with a prerequisite CL that moves stuff out of the 7 ctors into
> in-class initializers instead.
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[erikchen, 2017-05-10 17:31:40]

On 2017/05/09 18:31:31, Alexei Svitkine (slow) wrote:
> For 1, wanted to hear your perspective on this, as I can go either way. We
> could remove it post investigation or make it part of the API.
> 
> What do you think? With this CL, I was sort of thinking we can make that
> decision when cleaning up the crash keys - i.e. to expand the error support
> more at that time or to remove it.
I would advocate for removing the error codes post investigation, since I don't
know anyone that would actually use the error codes after you finish your
investigation. 

> 
> For 2, the changes to chrome_crash_reporter_client_win.cc is for
> consistency with crash_keys.cc - since there's two parallel lists that
> should be maintained. While the linked bug is about Mac specifically, the
> code path where CrashKeys are being added can be hit on Windows too, so the
> crash keys should be defined in both places.
> 
> On Tue, May 9, 2017 at 2:23 PM, <mailto:erikchen@chromium.org> wrote:
> 
> > Some questions:
> >
> > 1) Is this intended to be temporary or permanent code? If temporary,
> > please make
> > it very clear that you intend to remove all this code afterwards, with
> > TODOs,
> > links to crbugs, and updated CL description. If permanent, please don't
> > hack in
> > an implementation that only works for macOS POSIX, and please change the
> > Create() API to return an error.
> >
> > 2) I'm having trouble which platforms this code is intended to run on. It
> > looks
> > like this is only plumbed through for macOS POSIX, but I also see changes
> > to
> > *win files.
> >
> > https://codereview.chromium.org/2872503003/
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

[Nico, 2017-05-10 17:32:20]

On Wed, May 10, 2017 at 1:31 PM, <erikchen@chromium.org> wrote:

> On 2017/05/09 18:31:31, Alexei Svitkine (slow) wrote:
> > For 1, wanted to hear your perspective on this, as I can go either way.
> We
> > could remove it post investigation or make it part of the API.
> >
> > What do you think? With this CL, I was sort of thinking we can make that
> > decision when cleaning up the crash keys - i.e. to expand the error
> support
> > more at that time or to remove it.
> I would advocate for removing the error codes post investigation, since I
> don't
> know anyone that would actually use the error codes after you finish your
> investigation.
>

(+1)


>
> >
> > For 2, the changes to chrome_crash_reporter_client_win.cc is for
> > consistency with crash_keys.cc - since there's two parallel lists that
> > should be maintained. While the linked bug is about Mac specifically, the
> > code path where CrashKeys are being added can be hit on Windows too, so
> the
> > crash keys should be defined in both places.
> >
> > On Tue, May 9, 2017 at 2:23 PM, <mailto:erikchen@chromium.org> wrote:
> >
> > > Some questions:
> > >
> > > 1) Is this intended to be temporary or permanent code? If temporary,
> > > please make
> > > it very clear that you intend to remove all this code afterwards, with
> > > TODOs,
> > > links to crbugs, and updated CL description. If permanent, please don't
> > > hack in
> > > an implementation that only works for macOS POSIX, and please change
> the
> > > Create() API to return an error.
> > >
> > > 2) I'm having trouble which platforms this code is intended to run on.
> It
> > > looks
> > > like this is only plumbed through for macOS POSIX, but I also see
> changes
> > > to
> > > *win files.
> > >
> > > https://codereview.chromium.org/2872503003/
> > >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Chromium-reviews" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email
> > to mailto:chromium-reviews+unsubscribe@chromium.org.
>
>
>
> https://codereview.chromium.org/2872503003/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alexei Svitkine (slow), 2017-05-10 17:34:42]

SGTM. Does the CL lgty otherwise? I'll rebase it on
https://codereview.chromium.org/2876593002/ once that lands.

On Wed, May 10, 2017 at 1:32 PM, Nico Weber <thakis@chromium.org> wrote:

> On Wed, May 10, 2017 at 1:31 PM, <erikchen@chromium.org> wrote:
>
>> On 2017/05/09 18:31:31, Alexei Svitkine (slow) wrote:
>> > For 1, wanted to hear your perspective on this, as I can go either way.
>> We
>> > could remove it post investigation or make it part of the API.
>> >
>> > What do you think? With this CL, I was sort of thinking we can make that
>> > decision when cleaning up the crash keys - i.e. to expand the error
>> support
>> > more at that time or to remove it.
>> I would advocate for removing the error codes post investigation, since I
>> don't
>> know anyone that would actually use the error codes after you finish your
>> investigation.
>>
>
> (+1)
>
>
>>
>> >
>> > For 2, the changes to chrome_crash_reporter_client_win.cc is for
>> > consistency with crash_keys.cc - since there's two parallel lists that
>> > should be maintained. While the linked bug is about Mac specifically,
>> the
>> > code path where CrashKeys are being added can be hit on Windows too, so
>> the
>> > crash keys should be defined in both places.
>> >
>> > On Tue, May 9, 2017 at 2:23 PM, <mailto:erikchen@chromium.org> wrote:
>> >
>> > > Some questions:
>> > >
>> > > 1) Is this intended to be temporary or permanent code? If temporary,
>> > > please make
>> > > it very clear that you intend to remove all this code afterwards, with
>> > > TODOs,
>> > > links to crbugs, and updated CL description. If permanent, please
>> don't
>> > > hack in
>> > > an implementation that only works for macOS POSIX, and please change
>> the
>> > > Create() API to return an error.
>> > >
>> > > 2) I'm having trouble which platforms this code is intended to run
>> on. It
>> > > looks
>> > > like this is only plumbed through for macOS POSIX, but I also see
>> changes
>> > > to
>> > > *win files.
>> > >
>> > > https://codereview.chromium.org/2872503003/
>> > >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Chromium-reviews" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> email
>> > to mailto:chromium-reviews+unsubscribe@chromium.org.
>>
>>
>>
>> https://codereview.chromium.org/2872503003/
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[erikchen, 2017-05-10 17:42:11]

lgtm

https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
File base/memory/shared_memory_posix.cc (right):

https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
base/memory/shared_memory_posix.cc:189: if (fstat(fileno(fp.get()), &stat) != 0)
shouldn't every "return false" be prefixed with last_error_ update?

[Alexei Svitkine (slow), 2017-05-10 17:46:22]

https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
File base/memory/shared_memory_posix.cc (right):

https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
base/memory/shared_memory_posix.cc:189: if (fstat(fileno(fp.get()), &stat) != 0)
On 2017/05/10 17:42:11, erikchen wrote:
> shouldn't every "return false" be prefixed with last_error_ update?

This is in shared_memory_posix.cc code which Mac doesn't call. So this doesn't
need an update to investigate the Mac issue.

The only reason it has changes is it uses PrepareMapFile() and
CreateAnonymousSharedMemory() helpers that are shared with the Mac code and
whose signature is being changed.

[erikchen, 2017-05-10 17:50:09]

On 2017/05/10 17:46:22, Alexei Svitkine (slow) wrote:
>
https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
> File base/memory/shared_memory_posix.cc (right):
> 
>
https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
> base/memory/shared_memory_posix.cc:189: if (fstat(fileno(fp.get()), &stat) !=
0)
> On 2017/05/10 17:42:11, erikchen wrote:
> > shouldn't every "return false" be prefixed with last_error_ update?
> 
> This is in shared_memory_posix.cc code which Mac doesn't call. So this doesn't
> need an update to investigate the Mac issue.
> 
> The only reason it has changes is it uses PrepareMapFile() and
> CreateAnonymousSharedMemory() helpers that are shared with the Mac code and
> whose signature is being changed.

Please update your CL description to indicate that you're only targeting macOS>

[erikchen, 2017-05-10 17:50:23]

On 2017/05/10 17:50:09, erikchen wrote:
> On 2017/05/10 17:46:22, Alexei Svitkine (slow) wrote:
> >
>
https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
> > File base/memory/shared_memory_posix.cc (right):
> > 
> >
>
https://codereview.chromium.org/2872503003/diff/120001/base/memory/shared_mem...
> > base/memory/shared_memory_posix.cc:189: if (fstat(fileno(fp.get()), &stat)
!=
> 0)
> > On 2017/05/10 17:42:11, erikchen wrote:
> > > shouldn't every "return false" be prefixed with last_error_ update?
> > 
> > This is in shared_memory_posix.cc code which Mac doesn't call. So this
doesn't
> > need an update to investigate the Mac issue.
> > 
> > The only reason it has changes is it uses PrepareMapFile() and
> > CreateAnonymousSharedMemory() helpers that are shared with the Mac code and
> > whose signature is being changed.
> 
> Please update your CL description to indicate that you're only targeting
macOS>

And also please indicate that this is a temporary debugging CL.

[Alexei Svitkine (slow), 2017-05-10 17:54:54]

Description was changed from

==========
Add crash keys about field trial shared memory errors.

This is needed to figure out the cause of the failures in field
trial shared memory allocation & map operations.

Adds crash keys for the error values when shared memory
APIs fail from field trial code, to diagnose the crash causes.

BUG=703649
==========

to

==========
Add crash keys about field trial shared memory errors.

This is needed to figure out the cause of the failures in field
trial shared memory allocation & map operations.

Adds crash keys for the error values when shared memory
APIs fail from field trial code, to diagnose the crash causes.

The temporary logging CL adds coverage to Mac codepaths
specifically, since that is the issue being investigated. The
plan is to clean up the code once the crbug has been fixed.

BUG=703649
==========

[Alexei Svitkine (slow), 2017-05-10 17:55:16]

Done. Thanks!

Will wait for the other CL to land, rebase and them land this one.

[Alexei Svitkine (slow), 2017-05-10 20:43:46]

The CQ bit was checked by asvitkine@chromium.org

[Alexei Svitkine (slow), 2017-05-10 20:43:47]

The patchset sent to the CQ was uploaded after l-g-t-m from
erikchen@chromium.org, thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/2872503003/#ps140001
(title: "Rebased")

[commit-bot: I haz the power, 2017-05-10 20:44:39]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-11 00:22:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-11 00:22:12]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Alexei Svitkine (slow), 2017-05-11 00:39:57]

The CQ bit was checked by asvitkine@chromium.org

[commit-bot: I haz the power, 2017-05-11 00:40:54]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-11 04:10:41]

CQ is committing da patch.

Bot data: {"patchset_id": 140001, "attempt_start_ts": 1494463197261710,
"parent_rev": "f435c1e84c2fb1cdfe7b68739cfd05ff8c49dee4", "commit_rev":
"0fe371d918bf4d467619c1cd2d9fd9f3ee117add"}

[commit-bot: I haz the power, 2017-05-11 04:10:52]

Description was changed from

==========
Add crash keys about field trial shared memory errors.

This is needed to figure out the cause of the failures in field
trial shared memory allocation & map operations.

Adds crash keys for the error values when shared memory
APIs fail from field trial code, to diagnose the crash causes.

The temporary logging CL adds coverage to Mac codepaths
specifically, since that is the issue being investigated. The
plan is to clean up the code once the crbug has been fixed.

BUG=703649
==========

to

==========
Add crash keys about field trial shared memory errors.

This is needed to figure out the cause of the failures in field
trial shared memory allocation & map operations.

Adds crash keys for the error values when shared memory
APIs fail from field trial code, to diagnose the crash causes.

The temporary logging CL adds coverage to Mac codepaths
specifically, since that is the issue being investigated. The
plan is to clean up the code once the crbug has been fixed.

BUG=703649

Review-Url: https://codereview.chromium.org/2872503003
Cr-Commit-Position: refs/heads/master@{#470802}
Committed:
https://chromium.googlesource.com/chromium/src/+/0fe371d918bf4d467619c1cd2d9f...
==========

[commit-bot: I haz the power, 2017-05-11 04:10:53]

Committed patchset #3 (id:140001) as
https://chromium.googlesource.com/chromium/src/+/0fe371d918bf4d467619c1cd2d9f...

[Alexei Svitkine (slow), 2017-06-08 17:32:29]

A revert of this CL (patchset #3 id:140001) has been created in
https://codereview.chromium.org/2929013002/ by asvitkine@chromium.org.

The reason for reverting is: No crashes observed that this instrumentation was
meant to help with. Reverting the change..