Renderer crash when inspecting window opened in a different domain. |
||||||
Issue descriptionChrome Version: 57.0.2987.98 (Official Build) (64-bit) OS: All What steps will reproduce the problem? (1) Run chrome with --site-per-process. (2) Goto https://ehsan-karamad.github.io/bugs/701506.html. (3) Inspect the page, go to Sources tab and put a breakpoint on line 6 of the source file (the line which logs a message). (4) Press the button. A new window appears (if it is blocked, give permission and repeat the steps). (5) Go to the first tab. Verify if the new window has navigated to google.com and committed. If not, continue the debugger until it hits the same line again and verify. Repeat until the newly opened window commits. (6) Hover mouse over the window variable, |other|. What is the expected result? See properties of the object in a dropdown list. What happens instead? Renderer crashes.
,
Mar 14 2017
cc-ing nasko@ to help with the triage. Thanks!
,
Mar 14 2017
Here's a crash stack from a local Linux repro, where I hit a DCHECK. [1:1:0314/155538.429877:FATAL:ScriptWrappable.cpp(30)] Check failed: !wrapper.IsEmpty(). #0 0x7f0d0b6d6f1b base::debug::StackTrace::StackTrace() #1 0x7f0d0b6d55ac base::debug::StackTrace::StackTrace() #2 0x7f0d0b743aaf logging::LogMessage::~LogMessage() #3 0x7f0cf0e11c3f blink::ScriptWrappable::wrap() #4 0x7f0cf0d90332 blink::ToV8() #5 0x7f0cf26f82cb blink::DOMWindowV8Internal::historyAttributeGetter() #6 0x7f0cf26f8175 blink::V8Window::historyAttributeGetterCallback() #7 0x7f0cfbff3f1b v8::internal::FunctionCallbackArguments::Call() #8 0x7f0cfc0c63c9 v8::internal::(anonymous namespace)::HandleApiCallHelper<>() #9 0x7f0cfc0c54bc v8::internal::Builtins::InvokeApiFunction() #10 0x7f0cfc655fa6 v8::internal::Object::GetPropertyWithAccessor() #11 0x7f0cfc655489 v8::internal::Object::GetProperty() #12 0x7f0cfc58afd8 v8::internal::LoadIC::Load() #13 0x7f0cfc59101e v8::internal::KeyedLoadIC::Load() #14 0x7f0cfc5979cb v8::internal::__RT_impl_Runtime_KeyedLoadIC_Miss() #15 0x35c3fe004204 <unknown> +dcheng as this might involve V8/bindings.
,
Mar 14 2017
Here's a sample crash ID from Mac canary: 040b18aa60000000 Also +dgozman as this involves DevTools for OOPIFs.
,
Mar 14 2017
,
Mar 15 2017
A few more crash IDs for Linux. The both have (fixed) assigned bugs. a6e686e480000000 (issue 626725) 8b831d6820000000 (issue 486641) 5bab6eaea0000000 (multiple issues).
,
Jul 11 2017
It's fixed in ToT and based on bisect it looks like it was fixed by https://chromium.googlesource.com/chromium/src/+/a94ee9eb38e2003712667dfe217a5cb1a1763dd0 |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ekaramad@chromium.org
, Mar 14 2017