Add crash keys to LocalDOMWindow to help diagnose bug 621730.

Add crash keys to LocalDOMWindow to help diagnose bug 621730.

This change can be reverted after a day or two of data.

BUG=621730
patch from issue 2101773002 at patchset 20001 (http://crrev.com/2101773002#ps20001)

Committed: https://crrev.com/65deb8a7baf2360be817158b6f87aaf7a93cd4ca
Cr-Commit-Position: refs/heads/master@{#402854}

[Yuki, 2016-06-28 12:02:13]

yukishiino@chromium.org changed reviewers:
+ dcheng@chromium.org, haraken@chromium.org

[Yuki, 2016-06-28 12:02:14]

Could you guys review this CL?

I'm taking over http://crrev.com/2101773002 .

[Yuki, 2016-06-28 12:05:40]

yukishiino@chromium.org changed reviewers:
+ rsesek@chromium.org

[Yuki, 2016-06-28 12:05:40]

@rsesek, could you review this CL as the owner of
  blimp/engine/app/blimp_engine_crash_keys.cc
  chrome/common/crash_keys.cc

[Robert Sesek, 2016-06-28 14:25:56]

https://codereview.chromium.org/2101283002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/debug/CrashLogging.h (right):

https://codereview.chromium.org/2101283002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/debug/CrashLogging.h:1: // Copyright 2016 The
Chromium Authors. All rights reserved.
Can this be split out into a separate CL? Since the crash keys are temporary,
that would make it easier to revert later.

[Yuki, 2016-06-28 23:09:54]

https://codereview.chromium.org/2101283002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/wtf/debug/CrashLogging.h (right):

https://codereview.chromium.org/2101283002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/wtf/debug/CrashLogging.h:1: // Copyright 2016 The
Chromium Authors. All rights reserved.
On 2016/06/28 14:25:56, Robert Sesek wrote:
> Can this be split out into a separate CL? Since the crash keys are temporary,
> that would make it easier to revert later.

Already done at https://codereview.chromium.org/2105763002/

[dcheng, 2016-06-29 09:58:40]

lgtm

[Robert Sesek, 2016-06-29 16:49:29]

lgtm

[Yuki, 2016-06-29 16:50:38]

The CQ bit was checked by yukishiino@chromium.org

[commit-bot: I haz the power, 2016-06-29 16:51:09]

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, 2016-06-29 17:37:42]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-06-29 17:37:44]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-06-29 17:40:15]

Description was changed from

==========
Add crash keys to LocalDOMWindow to help diagnose bug 621730.

This change can be reverted after a day or two of data.

BUG=621730

patch from issue 2101773002 at patchset 20001
(http://crrev.com/2101773002#ps20001)
==========

to

==========
Add crash keys to LocalDOMWindow to help diagnose bug 621730.

This change can be reverted after a day or two of data.

BUG=621730

patch from issue 2101773002 at patchset 20001
(http://crrev.com/2101773002#ps20001)

Committed: https://crrev.com/65deb8a7baf2360be817158b6f87aaf7a93cd4ca
Cr-Commit-Position: refs/heads/master@{#402854}
==========

[commit-bot: I haz the power, 2016-06-29 17:40:26]

Patchset 3 (id:??) landed as
https://crrev.com/65deb8a7baf2360be817158b6f87aaf7a93cd4ca
Cr-Commit-Position: refs/heads/master@{#402854}

[haraken, 2016-06-29 23:42:38]

LGTM

[falken, 2016-07-11 01:11:47]

How do these work?

WTF::debug::ScopedCrashKey("postmessage_src_origin",
event->origin().utf8().data());

Isn't the temporary ScopedCrashKey object destroyed before the crash?

[Yuki, 2016-07-11 04:07:56]

On 2016/07/11 01:11:47, falken wrote:
> How do these work?
> 
> WTF::debug::ScopedCrashKey("postmessage_src_origin",
> event->origin().utf8().data());
> 
> Isn't the temporary ScopedCrashKey object destroyed before the crash?

For this specific case, the hang was happening during a call to
dispatchMessageEventWithOriginCheck(), so the temporary ScopedCrashKey object
was alive when the hang happened.

[falken, 2016-07-11 04:46:19]

On 2016/07/11 at 04:07:56, yukishiino wrote:
> On 2016/07/11 01:11:47, falken wrote:
> > How do these work?
> > 
> > WTF::debug::ScopedCrashKey("postmessage_src_origin",
> > event->origin().utf8().data());
> > 
> > Isn't the temporary ScopedCrashKey object destroyed before the crash?
> 
> For this specific case, the hang was happening during a call to
dispatchMessageEventWithOriginCheck(), so the temporary ScopedCrashKey object
was alive when the hang happened.

That doesn't seem to work with this test case:

class A {
 public:
  A() { printf("ctor %p\n", this); }
  ~A() { printf("dtor %p\n" , this); }
};

int main() {
  printf("1\n");
  A();
  printf("2\n");
  A();
  printf("3\n");
}

1
ctor 0x7ffcb8374c5f
dtor 0x7ffcb8374c5f
2
ctor 0x7ffcb8374c5f
dtor 0x7ffcb8374c5f
3

The temporaries are destroyed by the time the next statement is executed.

[falken, 2016-07-11 04:50:25]

(The reason this caught my eye is I copied this code for
https://codereview.chromium.org/2134623002 which isn't working, I think because
of temporary object destruction.)

[Yuki, 2016-07-11 05:23:53]

On 2016/07/11 04:50:25, falken wrote:
> (The reason this caught my eye is I copied this code for
> https://codereview.chromium.org/2134623002 which isn't working, I think
because
> of temporary object destruction.)

Uh, ga!  Now I understand the issue.  It's a bug.
We need to declare a variable to keep it alive.
I overlooked it.

I myself copy&pasted it from https://codereview.chromium.org/2101773002/