The context looks is missing closure and previous context fields.

0x206941f1f6c1: [FixedArray]
 - length: 7
  [0]: 0x2a57fe602311 <undefined>
  [1]: 0x2a57fe602311 <undefined>
  [2]: 0x2a57fe602351 <the hole>
  [3]: 0x327b87f95bc1 <FixedArray[242]>
  [4]: 1
  [5]: 0xde5397ad4d1 <a Promise with map 0x3261c22254b9>
  [6]: 0x2a57fe6023b1 <true>

Seems to be a promise context.

Yes, the context held by the promise resolving builtins(kPromiseResolveClosure, kPromiseRejectClosure) don't have a closure and previous context field. The two builtins share the context, so there isn't a correct closure field to be set here.

I see multiple potential fixes --
1) Add null checks before accessing these fields in ExtractContextReferences. This is a pretty minimal, but ad hoc solution.
2) Create two different contexts for each of the builtins. This has unnecessary extra perf/memory overhead.
3) Add a new context type (eg. PromiseContext) that fails the is_declaration_context() check. This would involve having a new promise context map.
4) Don't use the context to store the builtin metadata(promise, debugevent, already_visited) and instead use some other slot/field in JSFunction. This is probably going to be a non trivial change and not worth it.

Georg, thoughts on the above solutions?

It looks strange to me that the accessor declared as JSFunction* can be undefined. Isn't it against the contract?

Users experienced this crash on the following builds:

Linux Dev 56.0.2922.1 -  2.16 CPM, 3 reports, 1 clients (signature v8::internal::V8HeapExplorer::ExtractContextReferences)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

I think you should just set that context's closure to an empty function (that's what we do for the native context too, see bootstrapper.cc).

Regarding (2) I think you are misunderstanding: the closure field is supposed to point to the function in which the context was created.

 Issue 666249  has been merged into this issue.

Users experienced this crash on the following builds:

Mac Canary 57.0.2926.0 -  0.27 CPM, 5 reports, 4 clients (signature v8::internal::V8HeapExplorer::ExtractContextReferences)
Linux Dev 56.0.2922.1 -  2.08 CPM, 5 reports, 1 clients (signature v8::internal::V8HeapExplorer::ExtractContextReferences)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Landed https://codereview.chromium.org/2528603002/ which should fix this. 

[Automated comment] No milestone found on Merge-Request (i.e. merge-request-# label).

Friendly ping. I wonder how long it takes to review the merge request. Adding Chrome build number to the merge request per comment #14.

This is marked as Platform>DevTools>Performance. Only Blink>JavaScript are valid "proper" V8 bugs thus it was not showing up on V8's merge radar.

It also did not show up on Chrome's radar because of #14.

If this bug is fixe,d please set it to fixed btw.

I'll mark it so as soon as I get the fix merged into M56.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/1ed70b6c094a846fcc3aff8b4534e735697daa63

commit 1ed70b6c094a846fcc3aff8b4534e735697daa63
Author: gsathya <gsathya@chromium.org>
Date: Tue Dec 06 20:15:38 2016

Merged: [promises] Set promise context's closure to be an empty function

Revision: a29b658eec3324716e39d44add188499f298c590

BUG= chromium:666984 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=neis@chromium.org

Review-Url: https://codereview.chromium.org/2555023002
Cr-Commit-Position: refs/branch-heads/5.6@{#38}
Cr-Branched-From: bdd3886218dfe76e8560eb8a18401942452ae859-refs/heads/5.6.326@{#1}
Cr-Branched-From: 879f6599eee6e1dfcbe9a24bf688b261c03e9558-refs/heads/master@{#41014}

[modify] https://crrev.com/1ed70b6c094a846fcc3aff8b4534e735697daa63/src/promise-utils.cc

If there is no pending work please remove Merge-Approved-56 label.