Crash in v8::VisitorAdapter::VisitEmbedderReference running maps_pixel_test on Mac OS |
|||||||||||||||
Issue descriptionSeveral failures are seen on the mac_chromium_rel_ng tryserver running maps_pixel_test: https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_ng?numbuilds=200 and also on the waterfall bots, for example: https://build.chromium.org/p/chromium.gpu/builders/Mac%2010.10%20Retina%20Release%20%28AMD%29?numbuilds=200 The renderer process running the Maps test crashes. The stack trace is (full stdout attached from one run): Operating system: Mac OS X 10.10.5 14F1021 CPU: amd64 family 6 model 70 stepping 1 8 CPUs GPU: UNKNOWN Crash reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash address: 0x9ffffffff Process uptime: 1 seconds Thread 0 (crashed) 0 Chromium Framework!v8::Context::Exit() + 0x100 1 Chromium Framework!v8::VisitorAdapter::VisitEmbedderReference(v8::internal::Object**, unsigned short) + 0x1a 2 Chromium Framework!v8::internal::GlobalHandles::IterateAllRootsWithClassIds(v8::internal::ObjectVisitor*) + 0x6f 3 Chromium Framework!v8::Isolate::VisitHandlesWithClassIds(v8::PersistentHandleVisitor*) + 0x3e 4 Chromium Framework!blink::V8GCController::gcPrologue(v8::Isolate*, v8::GCType, v8::GCCallbackFlags) + 0x4a3 5 Chromium Framework!v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) + 0x201 6 Chromium Framework!v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, char const*, char const*, v8::GCCallbackFlags) + 0x310 7 Chromium Framework!v8::internal::Factory::NewHeapNumber(double, v8::internal::MutableMode, v8::internal::PretenureFlag) + 0x66 8 Chromium Framework!v8::internal::Runtime_AllocateHeapNumber(int, v8::internal::Object**, v8::internal::Isolate*) + 0x1f9 9 0xb9241806587 10 0xb92419c787b 11 0xb9241a8039e 12 0xb924183c7bb 13 0xb9241a7fc19 14 0xb9241a7f151 15 0xb924183c7bb 16 0xb9241a74aa8 17 0xb9241809255 18 0xb9241a5813c 19 0xb9241a51279 20 0xb9241a57c48 21 0xb9241a517cd 22 0xb9241a51279 23 0xb9241a4fb07 24 0xb9241a4f763 25 0xb9241a2cc0b 26 0xb9241a22811 27 0xb9241809255 28 0xb9241a21c9a 29 0xb9241a180f4 30 0xb9241809255 31 0xb924183c7b6 32 0xb9241a15edd 33 0xb9241809255 34 0xb9241a154fc 35 0xb9241844c03 36 0xb924181420f 37 Chromium Framework!v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, bool, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, v8::internal::Handle<v8::internal::Object>) + 0x210 38 Chromium Framework!v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) + 0x2e8 39 Chromium Framework!v8::Script::Run(v8::Local<v8::Context>) + 0x29f 40 Chromium Framework!blink::V8ScriptRunner::runCompiledScript(v8::Isolate*, v8::Local<v8::Script>, blink::ExecutionContext*) + 0x1d7 41 Chromium Framework!blink::ScriptController::executeScriptAndReturnValue(v8::Local<v8::Context>, blink::ScriptSourceCode const&, blink::AccessControlStatus, double*) + 0x309 42 Chromium Framework!blink::ScriptController::evaluateScriptInMainWorld(blink::ScriptSourceCode const&, blink::AccessControlStatus, blink::ScriptController::ExecuteScriptPolicy, double*) + 0x108 43 Chromium Framework!blink::ScriptController::executeScriptInMainWorld(blink::ScriptSourceCode const&, blink::AccessControlStatus, double*) + 0x46 44 Chromium Framework!blink::ScriptLoader::executeScript(blink::ScriptSourceCode const&, double*) + 0xa2d 45 Chromium Framework!blink::ScriptLoader::prepareScript(WTF::TextPosition const&, blink::ScriptLoader::LegacyTypeSupport) + 0x4a9 46 Chromium Framework!blink::HTMLScriptRunner::runScript(blink::Element*, WTF::TextPosition const&) + 0x175 47 Chromium Framework!blink::HTMLScriptRunner::execute(blink::Element*, WTF::TextPosition const&) + 0x16d 48 Chromium Framework!blink::HTMLDocumentParser::runScriptsForPausedTreeBuilder() + 0x44 49 Chromium Framework!blink::HTMLDocumentParser::processParsedChunkFromBackgroundParser(WTF::PassOwnPtr<blink::HTMLDocumentParser::ParsedChunk>) + 0x6ed 50 Chromium Framework!blink::HTMLDocumentParser::pumpPendingSpeculations() + 0x373 51 Chromium Framework!blink::PendingScript::streamingFinished() + 0x6b 52 Chromium Framework!base::internal::Invoker<base::IndexSequence<0ul>, base::internal::BindState<base::internal::RunnableAdapter<void (*)(std::__1::unique_ptr<blink::WebTaskRunner::Task, std::__1::default_delete<blink::WebTaskRunner::Task> >)>, void (std::__1::unique_ptr<blink::WebTaskRunner::Task, std::__1::default_delete<blink::WebTaskRunner::Task> >), base::internal::PassedWrapper<std::__1::unique_ptr<blink::WebTaskRunner::Task, std::__1::default_delete<blink::WebTaskRunner::Task> > > >, base::internal::InvokeHelper<false, void, base::internal::RunnableAdapter<void (*)(std::__1::unique_ptr<blink::WebTaskRunner::Task, std::__1::default_delete<blink::WebTaskRunner::Task> >)> >, void ()>::Run(base::internal::BindStateBase*) + 0x68 53 Chromium Framework!base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask const&) + 0xbb 54 Chromium Framework!scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(scheduler::internal::WorkQueue*, scheduler::internal::TaskQueueImpl::Task*) + 0x31a 55 Chromium Framework!scheduler::TaskQueueManager::DoWork(base::TimeTicks, bool) + 0x1fb 56 Chromium Framework!base::internal::Invoker<base::IndexSequence<0ul, 1ul, 2ul>, base::internal::BindState<base::internal::RunnableAdapter<void (scheduler::TaskQueueManager::*)(base::TimeTicks, bool)>, void (scheduler::TaskQueueManager*, base::TimeTicks, bool), base::WeakPtr<scheduler::TaskQueueManager>, base::TimeTicks, bool>, base::internal::InvokeHelper<true, void, base::internal::RunnableAdapter<void (scheduler::TaskQueueManager::*)(base::TimeTicks, bool)> >, void ()>::Run(base::internal::BindStateBase*) + 0x73 57 Chromium Framework!base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask const&) + 0xbb 58 Chromium Framework!base::MessageLoop::RunTask(base::PendingTask const&) + 0x243 59 Chromium Framework!base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) + 0x2c 60 Chromium Framework!base::MessageLoop::DoWork() + 0x12b 61 Chromium Framework!base::MessagePumpCFRunLoopBase::RunWork() + 0x33 62 Chromium Framework!base::mac::CallWithEHFrame(void () block_pointer) + 0xa 63 Chromium Framework!base::MessagePumpCFRunLoopBase::RunWorkSource(void*) + 0x44 64 CoreFoundation + 0x80a01 65 CoreFoundation + 0x72b8d 66 CoreFoundation + 0x721bf 67 CoreFoundation + 0x71bd8 68 Foundation + 0x90b29 69 Chromium Framework!base::MessagePumpNSRunLoop::DoRun(base::MessagePump::Delegate*) + 0x7e 70 Chromium Framework!base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) + 0x7f 71 Chromium Framework!base::MessageLoop::RunHandler() + 0xd7 72 Chromium Framework!base::RunLoop::Run() + 0x33 73 Chromium Framework!base::MessageLoop::Run() + 0x67 74 Chromium Framework!content::RendererMain(content::MainFunctionParams const&) + 0x2df 75 Chromium Framework!content::ContentMainRunnerImpl::Run() + 0x322 76 Chromium Framework!content::ContentMain(content::ContentMainParams const&) + 0x36 77 Chromium Framework!ChromeMain + 0x3a 78 Chromium Helper!main + 0x212 79 Chromium Helper!start + 0x34 The first failure on https://build.chromium.org/p/chromium.gpu/builders/Mac%2010.10%20Retina%20Release%20%28AMD%29?numbuilds=200 was around May 6. V8 team, could you please investigate any GC changes that were introduced around that time?
,
May 9 2016
,
May 9 2016
Could this be related to recent Oilpan work around incremental marking of V8 wrappers?
,
May 9 2016
,
May 10 2016
I dispute that claim. This crash was not happening on Chrome's bots before about a week ago. It is a new failure that is affecting Chrome's commit queue, and is much higher priority than Issue 459380, which is marked P2 and has been open for over a year.
,
May 10 2016
Assigning to the current memory sheriff.
,
May 10 2016
,
May 10 2016
Issue 604754 has been merged into this issue.
,
May 10 2016
From discussion with jochen@: - He was not able to reproduce locally - He suggests enabling ASAN and, paradoxically, v8_target_arch=arm on one of the Mac bots on the chromium.gpu.fyi waterfall (which will make all of V8's jitted code go through the ARM simulator) to try to catch the error as it happens I'm not confident that this approach will catch the bug we're seeing -- it is a huge change in behavior. Also, it sounds like this is a fairly long-term plan for diagnosing this bug, where it is a clear regression that made it in within the past two weeks. I think the appropriate thing to do would be to stop V8 rolls and revert V8 back to a known good state, for example 2c5a2c5a06c94c5746f3c67deef0abec1b739972 from: https://build.chromium.org/p/chromium.gpu.fyi/builders/Mac%2010.10%20Release%20%28ATI%29/builds/10486 Then let's see whether mac_chromium_rel_ng is stabilized for a day or so, and then try bisecting in the V8 range. https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_ng?numbuilds=200 is showing some 10% of runs failing with this error, so it should be obvious when it's resolved. If it's not a V8 bug but instead some sort of memory error introduced in Blink recently, then eliminating V8 changes from the possible causes would also help narrow down the problem.
,
May 10 2016
Note: this failure of WebglConformance.conformance_textures_webgl_canvas_tex_2d_rgb_rgb_unsigned_short_5_6_5 on Windows looks similar: https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/218443 Stack: [ RUN ] WebglConformance.conformance_textures_webgl_canvas_tex_2d_rgb_rgb_unsigned_short_5_6_5 Backtrace: v8::internal::Isolate::set_context [0x6776862E+14] v8::Context::Exit [0x6774DF31+177] blink::V8CSSStyleDeclaration::visitDOMWrapper [0x6858E5D3+179] blink::MajorGCWrapperVisitor::VisitPersistentHandle [0x68469007+503] v8::VisitorAdapter::VisitEmbedderReference [0x67765F58+24] v8::internal::GlobalHandles::IterateAllRootsWithClassIds [0x696E93A5+341] v8::Isolate::VisitHandlesWithClassIds [0x67765F8D+45] blink::MajorGCWrapperVisitor::notifyFinished [0x6846A102+322] blink::V8GCController::gcPrologue [0x68469BE0+528] v8::internal::Heap::CallGCPrologueCallbacks [0x67772B77+215] v8::internal::Heap::PerformGarbageCollection [0x67780834+372] v8::internal::Heap::CollectGarbage [0x67773A48+424] v8::internal::Factory::NewHeapNumber [0x696F3875+165] v8::internal::BasicJsonStringifier::StringifyString [0x695AC211+1873] v8::internal::Runtime_AllocateHeapNumber [0x695A4E64+100] (No symbol) [0x2250A366] (No symbol) [0x2250A7D0] (No symbol) [0x28721FFD] (No symbol) [0x287507E7] (No symbol) [0x2250BA76] (No symbol) [0x28750212] (No symbol) [0x2250BA76] (No symbol) [0x3CDDAFAA] (No symbol) [0x3CDD9C5B] (No symbol) [0x3CDD9AEA] (No symbol) [0x287315C9] v8::internal::StackGuard::ThreadLocal::Initialize [0x696E20E3+467] v8::internal::Execution::Call [0x696E1A31+449] v8::Script::Run [0x6775F365+501] blink::V8ScriptRunner::runCompiledScript [0x685550D2+562] blink::ScriptController::executeScriptAndReturnValue [0x6846729E+862] blink::ScriptController::evaluateScriptInMainWorld [0x68466E75+277] blink::ScriptController::executeScriptInMainWorld [0x68467A4C+44] blink::ScriptLoader::executeScript [0x69897042+1154] blink::ScriptLoader::prepareScript [0x6989847D+957] blink::HTMLScriptRunner::runScript [0x67E3E122+258] blink::HTMLScriptRunner::execute [0x67E3CCFE+302] blink::HTMLDocumentParser::processParsedChunkFromBackgroundParser [0x67DE8388+2680] blink::HTMLDocumentParser::pumpPendingSpeculations [0x67DE8922+1106] ??$callInternal@$0A@$$Z$$V@?$PartBoundFunctionImpl@$00V?$tuple@$$QAV?$CrossThreadWeakPersistentThisPointer@VHTMLParserScheduler@blink@@@blink@@@std@@V?$FunctionWrapper@P8HTMLParserScheduler@blink@@AEXXZ@WTF@@$$V@WTF@@AAEXABU?$IndexSequence@$0A@@base@@@Z [0x67E3B146+134] ??R?$PartBoundFunctionImpl@$00V?$tuple@$$QAV?$CrossThreadWeakPersistentThisPointer@VHTMLParserScheduler@blink@@@blink@@@std@@V?$FunctionWrapper@P8HTMLParserScheduler@blink@@AEXXZ@WTF@@$$V@WTF@@UAEXXZ [0x67E3B57D+13] scheduler::WebTaskRunnerImpl::runTask [0x69A1089B+11] base::internal::Invoker<base::IndexSequence<0>,base::internal::BindState<base::internal::RunnableAdapter<void (__cdecl*)(std::unique_ptr<blink::WebTaskRunner::Task,std::default_delete<blink::WebTaskRunner::Task> >)>,void __cdecl(std::unique_ptr<blink::Web [0x6860BD6F+95] base::debug::TaskAnnotator::RunTask [0x67077F37+247] scheduler::TaskQueueManager::ProcessTaskFromWorkQueue [0x69A1796D+1037] scheduler::TaskQueueManager::DoWork [0x69A16E20+560] base::internal::Invoker<base::IndexSequence<0,1,2>,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall scheduler::TaskQueueManager::*)(base::TimeTicks,bool)>,void __cdecl(scheduler::TaskQueueManager *,base::TimeTicks,bool),base::Wea [0x69A17F7F+79] base::debug::TaskAnnotator::RunTask [0x67077F37+247] base::MessageLoop::RunTask [0x6704578B+1211] base::MessageLoop::DoWork [0x67044AF5+549] base::MessagePumpDefault::Run [0x6707A40B+299] base::MessageLoop::RunHandler [0x670452C7+103] base::RunLoop::Run [0x6707A579+41] base::MessageLoop::Run [0x67045252+98] content::RendererMain [0x686EC5FE+670] content::RunNamedProcessTypeMain [0x6701DDF4+260] content::ContentMainRunnerImpl::Run [0x6701DCA1+321] content::ContentMain [0x6701ADD3+35] ChromeMain [0x66F74AE6+118] MainDllLoader::Launch [0x013382FC+812] wWinMain [0x01337667+567] __scrt_common_main_seh [0x013A833C+253] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:255) ... So this is probably not Mac-specific and not specific to maps_pixel_test, either. It just happens to show up most often with that combination.
,
May 11 2016
Yes, inspector tests flakily triggers it also. Win dbg bots are a good place to look, e.g., https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Win7__dbg_/5607/layout-test-results/inspector/tracing/timeline-style-recalc-all-invalidator-types-crash-log.txt
,
May 11 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/24abea527df01d35b7afd8656009f09944019d8b commit 24abea527df01d35b7afd8656009f09944019d8b Author: jochen <jochen@chromium.org> Date: Wed May 11 13:08:11 2016 Revert of Remove Oilpan-only StyleSheet/ test failures from TestExpectations (patchset #6 id:100001 of https://codereview.chromium.org/1904423002/ ) Reason for revert: speculative revert to see whether this caused crbug.com/610340 BUG= 610340 Original issue's description: > Remove Oilpan-only StyleSheet/ test failures from TestExpectations > > BUG= 585328 > > Committed: https://crrev.com/23d02793c61cf69b1818cd007cc39db1d2238b09 > Cr-Commit-Position: refs/heads/master@{#390285} TBR=haraken@chromium.org,oilpan-reviews@chromium.org,sigbjornf@opera.com,yukishiino@chromium.org,keishi@chromium.org # CQ was green on first patchset, manual rebase of TestExpectations NOTRY=true BUG= 585328 Review-Url: https://codereview.chromium.org/1968903002 Cr-Commit-Position: refs/heads/master@{#392907} [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/LayoutTests/TestExpectations [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/LayoutTests/fast/dom/StyleSheet/detached-parent-rule-without-wrapper-expected.txt [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/LayoutTests/fast/dom/StyleSheet/detached-parent-rule-without-wrapper.html [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/LayoutTests/fast/dom/StyleSheet/detached-stylesheet-without-wrapper-expected.txt [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/LayoutTests/fast/dom/StyleSheet/detached-stylesheet-without-wrapper.html [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/LayoutTests/fast/dom/StyleSheet/gc-declaration-parent-rule-expected.txt [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/LayoutTests/fast/dom/StyleSheet/gc-parent-rule-expected.txt [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/LayoutTests/fast/dom/StyleSheet/gc-parent-stylesheet-expected.txt [add] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/LayoutTests/platform/oilpan/fast/dom/StyleSheet/detached-parent-rule-without-wrapper-expected.txt [add] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/LayoutTests/platform/oilpan/fast/dom/StyleSheet/gc-parent-rule-expected.txt [delete] https://crrev.com/2f78eb16262f1442e4c2b0cc9a03689e5cc47353/third_party/WebKit/Source/bindings/core/v8/custom/V8CSSStyleRuleCustom.cpp [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/Source/bindings/core/v8/custom/custom.gypi [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/Source/core/css/CSSStyleDeclaration.idl [modify] https://crrev.com/24abea527df01d35b7afd8656009f09944019d8b/third_party/WebKit/Source/core/css/CSSStyleRule.idl
,
May 11 2016
maybe fixed? let's wait and see...
,
May 11 2016
Detected 13 new flakes for test/step "maps_pixel_test (with patch)". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyJwsSBUZsYWtlIhxtYXBzX3BpeGVsX3Rlc3QgKHdpdGggcGF0Y2gpDA. This message was posted automatically by the chromium-try-flakes app. Since flakiness is ongoing, the issue was moved back into Sheriff Bug Queue (unless already there).
,
May 11 2016
i can't see the error anymore on the waterfall. Esp. on the WebKit Win7 (dbg) bot, every run used to have this crash (if you check "show stderr" and look at the inspector tests you should find it), but now they're gone
,
May 11 2016
I'd be very interested to see/hear an explanation of what was wrong with the custom (?) wrapper.
,
May 11 2016
Me too :) In fact, the crashes I've seen don't have the custom visitDOMWrapper on the stack but the generated one
,
May 11 2016
,
May 11 2016
Jochen, thank you for tracking this down. I think the flakes reported in #14 all happened before your revert, and there are currently no failures of maps_pixel_test on https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_ng?numbuilds=200 . Blocking this on Issue 585328 and downgrading to P2. Whatever was wrong with the custom visitor needs to be fixed before re-landing it.
,
May 11 2016
The crash is happening because we instantiate a ContextScope in visitDOMWrapper. And conceptually there's no reason we have to create the ContextScope. I tried to remove the ContextScope a couple of months ago but didn't land due to some failures observed on win bots (https://codereview.chromium.org/1683493003/). I think a right fix would be to land the CL. I'll take a look.
,
May 12 2016
Issue 610623 has been merged into this issue.
,
May 12 2016
I suspect issue 610623 is a duplicate of this - is it possible that those css objects generate that many references that we overflow stuff?
,
May 12 2016
I guess that's possible.
,
May 13 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b1b2e5dd2b1f6c4b314a813987724812e13fbc18 commit b1b2e5dd2b1f6c4b314a813987724812e13fbc18 Author: haraken <haraken@chromium.org> Date: Fri May 13 10:12:33 2016 Remove Context::Scope from visitDOMWrapper visitDOMWrapper should not create a Context::Scope. Alternately, it should visit wrappers of all worlds (currently the binding layer is assuming that wrappers of all worlds are kept alive if any of the wrappers is alive). Also it is important to remove the Context::Scope because if DOM has a long reference chain to be visited, the Context::Scopes created on the stack can overflow and cause crashes. BUG= 455160 , 610340 Review-Url: https://codereview.chromium.org/1683493003 Cr-Commit-Position: refs/heads/master@{#393492} [modify] https://crrev.com/b1b2e5dd2b1f6c4b314a813987724812e13fbc18/third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp [modify] https://crrev.com/b1b2e5dd2b1f6c4b314a813987724812e13fbc18/third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.h [modify] https://crrev.com/b1b2e5dd2b1f6c4b314a813987724812e13fbc18/third_party/WebKit/Source/bindings/templates/interface.cpp [modify] https://crrev.com/b1b2e5dd2b1f6c4b314a813987724812e13fbc18/third_party/WebKit/Source/bindings/tests/results/core/V8TestInterface.cpp [modify] https://crrev.com/b1b2e5dd2b1f6c4b314a813987724812e13fbc18/third_party/WebKit/Source/bindings/tests/results/modules/V8TestInterface5.cpp
,
May 13 2016
,
May 17 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eb23b41351d08e79e222870c70d05151585fed26 commit eb23b41351d08e79e222870c70d05151585fed26 Author: adamk <adamk@chromium.org> Date: Mon May 16 23:59:34 2016 Make sure ScriptWrappables have a wrapper before calling setReference() Failure to check for a valid wrapper before calling setReference (and then into v8::Isolate::SetReference) results in NULL handles being visited (and crashing) during V8 GC. BUG= 610340 ,612206 Review-Url: https://codereview.chromium.org/1981013002 Cr-Commit-Position: refs/heads/master@{#393986} [modify] https://crrev.com/eb23b41351d08e79e222870c70d05151585fed26/third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp
,
May 31 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c3d6201e736206557251cfb9109197844fcfd340 commit c3d6201e736206557251cfb9109197844fcfd340 Author: haraken <haraken@chromium.org> Date: Tue May 31 10:03:16 2016 Remove unnecessary Context::Scope from V8CSSStyleRuleCustom This is a left-over of https://codereview.chromium.org/1683493003/. This CL removes it. BUG= 455160 , 610340 Review-Url: https://codereview.chromium.org/2024793002 Cr-Commit-Position: refs/heads/master@{#396808} [modify] https://crrev.com/c3d6201e736206557251cfb9109197844fcfd340/third_party/WebKit/Source/bindings/core/v8/custom/V8CSSStyleRuleCustom.cpp |
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by kbr@chromium.org
, May 9 2016