New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 777495 link

Starred by 5 users

Issue metadata

Status: WontFix
Owner:
Closed: Sep 26
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug



Sign in to add a comment

Check failed: script_state_->GetContext() == script_state_->GetIsolate()

Project Member Reported by jkarlin@chromium.org, Oct 23 2017

Issue description

ToT Check failure when visiting slashdot.org in release build. Can't seem to reproduce regularly.

[1:1:1023/135407.106664:FATAL:V0CustomElementConstructorBuilder.cpp(63)] Check failed: script_state_->GetContext() == script_state_->GetIsolate()->GetCurrentContext(). 
#0 0x7ff896b537f7 base::debug::StackTrace::StackTrace()
#1 0x7ff896b7b751 logging::LogMessage::~LogMessage()
#2 0x7ff88f153a1e blink::V0CustomElementConstructorBuilder::V0CustomElementConstructorBuilder()
#3 0x7ff88f4a3407 blink::Document::registerElement()
#4 0x7ff89007eccd blink::V8Document::registerElementMethodCallback()
#5 0x7ff89078302d v8::internal::FunctionCallbackArguments::Call()
#6 0x7ff89087ca34 v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
#7 0x7ff89087ad6a v8::internal::Builtin_Impl_HandleApiCall()
#8 0x7ff89087a720 v8::internal::Builtin_HandleApiCall()
#9 0x27a404204844 <unknown>

Received signal 6
#0 0x7ff896b537f7 base::debug::StackTrace::StackTrace()
#1 0x7ff896b532cf base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7ff896c98330 <unknown>
#3 0x7ff889d14c37 gsignal
#4 0x7ff889d18028 abort
#5 0x7ff896b513e2 base::debug::BreakDebugger()
#6 0x7ff896b7bb23 logging::LogMessage::~LogMessage()
#7 0x7ff88f153a1e blink::V0CustomElementConstructorBuilder::V0CustomElementConstructorBuilder()
#8 0x7ff88f4a3407 blink::Document::registerElement()
#9 0x7ff89007eccd blink::V8Document::registerElementMethodCallback()
#10 0x7ff89078302d v8::internal::FunctionCallbackArguments::Call()
#11 0x7ff89087ca34 v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
#12 0x7ff89087ad6a v8::internal::Builtin_Impl_HandleApiCall()
#13 0x7ff89087a720 v8::internal::Builtin_HandleApiCall()
#14 0x27a404204844 <unknown>
  r8: ffffb986400202e0  r9: ffffb986400202d0 r10: 0000000000000008 r11: 0000000000000202
 r12: 00007ffd26d1aa10 r13: 00000000000000a8 r14: 00007ffd26d1aa08 r15: 00007ffd26d1aa00
  di: 0000000000000001  si: 0000000000000001  bp: 00007ffd26d1a5c0  bx: 00007ffd26d1a5c0
  dx: 0000000000000006  ax: 0000000000000000  cx: 00007ff889d14c37  sp: 00007ffd26d1a418
  ip: 00007ff889d14c37 efl: 0000000000000202 cgf: 0000000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
 
Actually, it wasn't ToT. I had patched a CL on top of it which had a fairly large change to the network stack in it. Shouldn't be v8 related but who knows.

Comment 2 by adamk@chromium.org, Oct 31 2017

Components: -Blink>JavaScript Blink>Bindings
Cc: dominicc@chromium.org
Components: -Blink>Bindings Blink>HTML>CustomElements
This DCHECK seems unjustified to me. It's entirely possible for the holder context of the document to not equal the current context.

The current context is the context in which the "registerElement" function was defined, but the document might be in another context in the same world (for instance, in a same-document.domain frame).

This simple URL triggers the DCHECK:

data:text/html,<iframe srcdoc="Hello"></iframe><script>onload = function() { document.registerElement.apply(document.body.firstChild.contentDocument, ['example-777495', class Example777495 extends HTMLElement{}]); };</script>

What's less apparent to me is how this is happening on Slashdot. I haven't been able to reproduce with a little bit of browsing, and the above seems an odd thing for an author to do.

Bouncing to HTML team for triage.
Cc: yukishiino@chromium.org
(also cc-ing yukishiino@ as it might be of interest as the DCHECK has to do with the confusion of realms)
Issue 783597 has been merged into this issue.
Cc: bustamante@chromium.org w...@chromium.org ajha@chromium.org
Components: Blink>Bindings
Labels: -Pri-3 M-64 Stability-Sheriff-Desktop Hotlist-Dcheck-Albatross OS-Windows Pri-1
Owner: sriram...@samsung.com
Status: Assigned (was: Untriaged)
For some reason information was not copied over from duped issue.

Labels: -Stability-Sheriff-Desktop
Cc: hayato@chromium.org
Status: WontFix (was: Assigned)
We won't fix Custom Element V0 issues because it will be removed.  Closing.

Sign in to add a comment