Flaky crashes in FreeList::Allocate during WebGL2 conformance tests |
||||
Issue descriptionVarious WebGL2 conformance tests are flakily failing the assertion static_cast<size_t>(owner_->limit() - owner_->top()) < size_in_bytes in FreeList::Allocate. The first instance I can find of this is from Sunday, and there are at least 5 cases of this so far: https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_optional_gpu_tests_rel/builds/4289 https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_optional_gpu_tests_rel/builds/3415 https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_optional_gpu_tests_rel/builds/4293 https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_optional_gpu_tests_rel/builds/4308 https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_optional_gpu_tests_rel/builds/4318 Log snippet: # # Fatal error in ../../v8/src/heap/spaces.cc, line 2569 # Check failed: static_cast<size_t>(owner_->limit() - owner_->top()) < size_in_bytes (18446722654633761200 vs. 80). # ==== C stack trace =============================== 0 Chromium Framework 0x00000001092e98a3 v8::base::debug::StackTrace::StackTrace() + 19 1 Chromium Framework 0x00000001092e58bd V8_Fatal + 221 2 Chromium Framework 0x00000001061acd5a v8::internal::FreeList::Allocate(unsigned long) + 938 3 Chromium Framework 0x00000001061020c1 v8::internal::PagedSpace::AllocateRawUnaligned(int, v8::internal::PagedSpace::UpdateSkipList) + 65 4 Chromium Framework 0x0000000106101e1a v8::internal::Heap::AllocateRaw(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) + 474 5 Chromium Framework 0x000000010613d05f v8::internal::Heap::AllocateFillerObject(int, bool, v8::internal::AllocationSpace) + 31 6 Chromium Framework 0x00000001060e948e v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) + 46 7 Chromium Framework 0x00000001063edf34 v8::internal::__RT_impl_Runtime_AllocateInTargetSpace(v8::internal::Arguments, v8::internal::Isolate*) + 132 8 Chromium Framework 0x00000001063edbf4 v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object**, v8::internal::Isolate*) + 260
,
Oct 25 2016
Happening on Windows too: https://build.chromium.org/p/tryserver.chromium.win/builders/win_optional_gpu_tests_rel/builds/4684 https://chromium-swarm.appspot.com/user/task/3216369e4493cb10 WebglConformance_deqp_functional_gles3_shaderindexing_mat_02 (gpu_tests.webgl_conformance_integration_test.WebGLConformanceIntegrationTest) ... # # Fatal error in e:\b\c\b\win\src\v8\src\heap\spaces.cc, line 2568 # Check failed: static_cast<size_t>(owner_->limit() - owner_->top()) < size_in_bytes (3681183072 vs. 60). # Error initializing symbols (87). Dumping unresolved backtrace: 601ED030 5F5731C1 5F4FAE11 5F4FAC8D 5F4FAB97 5F52AC0E 5F4FF482 5F6F4FF6 5F6EEC8C Backtrace: (No symbol) [0x00000000] v8::base::OS::Abort [0x601E582D+13] V8_Fatal [0x601E534C+124] v8::internal::FreeList::Allocate [0x5F5731C1+177] v8::internal::PagedSpace::AllocateRawAligned [0x5F4FAE11+97] v8::internal::PagedSpace::AllocateRaw [0x5F4FAC8D+29] v8::internal::Heap::AllocateRaw [0x5F4FAB97+519] v8::internal::Heap::AllocateFillerObject [0x5F52AC0E+30] v8::internal::Factory::NewFillerObject [0x5F4FF482+34] v8::internal::Runtime_UnwindAndFindExceptionHandler [0x5F6F4FF6+14326] v8::internal::Runtime_AllocateInTargetSpace [0x5F6EEC8C+204] (No symbol) [0x19287A86] v8::internal::Runtime_CompileForOnStackReplacement [0x5F6C915C+204] (No symbol) [0x19287355] v8::internal::StackGuard::ThreadLocal::Initialize [0x5F4F31A3+931] RtlFreeHeap [0x772BE023+126] v8::internal::Execution::Call [0x5F4F2A09+137] v8::Function::Call [0x5F1E18E8+504] blink::V8ScriptRunner::callFunction [0x603C6ABE+397] blink::ScheduledAction::execute [0x6172068F+450] blink::ScheduledAction::execute [0x61720B92+299] blink::DOMTimer::fired [0x607706D7+379] blink::TimerBase::runInternal [0x603289E9+406] ??$MakeItSo@ABQ8WebMediaPlayerMSCompositor@content@@AEXXZABV?$WeakPtr@VWebMediaPlayerMSCompositor@content@@@base@@$$V@?$InvokeHelper@$00X@internal@base@@SAXABQ8WebMediaPlayerMSCompositor@content@@AEXXZABV?$WeakPtr@VWebMediaPlayerMSCompositor@content@@@2@@ [0x60DCD250+33] base::internal::Invoker<base::internal::BindState<void (__thiscall content::WebMediaPlayerMSCompositor::*)(void),base::WeakPtr<content::WebMediaPlayerMSCompositor> >,void __cdecl(void)>::Run [0x60DCE36A+19] base::debug::TaskAnnotator::RunTask [0x5FA7D098+280] blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue [0x60322501+715] blink::scheduler::TaskQueueManager::DoWork [0x60321A6E+462] base::internal::FunctorTraits<void (__thiscall blink::scheduler::TaskQueueManager::*)(base::TimeTicks,bool),void>::Invoke<base::WeakPtr<blink::scheduler::TaskQueueManager> const &,base::TimeTicks const &,bool const &> [0x60320DCA+34] base::internal::InvokeHelper<1,void>::MakeItSo<void (__thiscall blink::scheduler::TaskQueueManager::*const &)(base::TimeTicks,bool),base::WeakPtr<blink::scheduler::TaskQueueManager> const &,base::TimeTicks const &,bool const &> [0x60320E10+37] base::internal::Invoker<base::internal::BindState<void (__thiscall blink::scheduler::TaskQueueManager::*)(base::TimeTicks,bool),base::WeakPtr<blink::scheduler::TaskQueueManager>,base::TimeTicks,bool>,void __cdecl(void)>::RunImpl<void (__thiscall blink::sc [0x60320E2C+23] base::internal::Invoker<base::internal::BindState<void (__thiscall blink::scheduler::TaskQueueManager::*)(base::TimeTicks,bool),base::WeakPtr<blink::scheduler::TaskQueueManager>,base::TimeTicks,bool>,void __cdecl(void)>::Run [0x603227DA+22] base::debug::TaskAnnotator::RunTask [0x5FA7D098+280] base::MessageLoop::RunTask [0x5FA4324C+1228] base::MessageLoop::DoWork [0x5FA42305+597] base::MessagePumpDefault::Run [0x5FA7F9E0+416] base::MessageLoop::RunHandler [0x5FA42D71+305] base::RunLoop::Run [0x5FA51F39+41] content::RendererMain [0x60E41F92+486] content::RunNamedProcessTypeMain [0x5F9F69AF+176] content::ContentMainRunnerImpl::Run [0x5F9F68CE+274] content::ContentMain [0x5F9F5D4F+35] ChromeMain [0x5F05949E+158] MainDllLoader::Launch [0x00D94C6E+527] wWinMain [0x00D92954+342] __scrt_common_main_seh [0x00DDD2C8+246] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253) BaseThreadInitThunk [0x76AC337A+18] RtlInitializeExceptionChain [0x772C92B2+99] RtlInitializeExceptionChain [0x772C9285+54]
,
Oct 26 2016
,
Oct 26 2016
A couple more such flakes reported in https://bugs.chromium.org/p/chromium/issues/detail?id=619264#c109 .
,
Oct 27 2016
Cannot reproduce locally. I am going to add more checks: https://codereview.chromium.org/2455103002/
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/b7dae10e5b72a69c38b679dcf654f5f1178fd567 commit b7dae10e5b72a69c38b679dcf654f5f1178fd567 Author: ulan <ulan@chromium.org> Date: Thu Oct 27 16:08:01 2016 [heap] Add debug checks for linear allocation area top and limit. BUG= chromium:659165 Review-Url: https://codereview.chromium.org/2455103002 Cr-Commit-Position: refs/heads/master@{#40629} [modify] https://crrev.com/b7dae10e5b72a69c38b679dcf654f5f1178fd567/src/heap/spaces.cc
,
Oct 28 2016
The new check is triggering in https://chromium-swarm.appspot.com/user/task/3223b80ba88feb10 We have top() pointer larger than the limit(). Since the allocation comes from generated code, I suspect that this is caused by allocation folding either in turbofan or crankshaft. Ken, is there any chance to get coredumps from the bots? That would greatly speed up investigation. Otherwise, I'd have to do printf debugging in CLs.
,
Oct 28 2016
Ulan: full core dumps or minidumps? I don't know whether core dumps are generated but I think minidumps are, and we can investigate how to upload them to cloud storage.
,
Oct 28 2016
I reproduced the failure on the try bot with more debug output :) https://chromium-swarm.appspot.com/user/task/3224f995de8ac110 I think I can make progress in this issue without core dumps or minidumps. For similar flaky failures in future full core dumps would be ideal. Not sure about usefulness of minidumps. In this case it would depend on whether the minidump contains the generated code or not.
,
Oct 28 2016
OK. Let's discuss this again in the near future after the M56 branch point. We're pretty swamped till then.
,
Oct 30 2016
FYI, here's another crash under v8::internal::PagedSpace::AllocateRawUnaligned, though from the logs, it doesn't look like the same assertion failed. https://build.chromium.org/p/tryserver.chromium.win/builders/win_optional_gpu_tests_rel/builds/4807 https://chromium-swarm.appspot.com/user/task/322c814f96ba1d10 ---------- ChildEBP RetAddr Args to Child 0017d6fc 61669718 00000000 00000010 00000000 chrome_child!std::char_traits<char>::length+0x6 0017d724 61ae8471 0017d73c 00000000 63fa62f8 chrome_child!std::operator<<<std::char_traits<char> >+0x15 0017d7d4 61b8780f 0017d7f8 0017d7f4 640649e0 chrome_child!v8::base::MakeCheckOpString<unsigned char *,unsigned char *>+0x61 0017d800 61b0f7d4 00000010 00000010 00f01030 chrome_child!v8::internal::FreeList::Allocate+0x7f 0017d818 61b0f4db 0017d848 00000010 00000000 chrome_child!v8::internal::PagedSpace::AllocateRawUnaligned+0x54 0017d838 61b0f3d7 0017d864 00000010 00000000 chrome_child!v8::internal::PagedSpace::AllocateRaw+0x2b 0017d878 61b3f33e 0017d8a4 00000010 00000001 chrome_child!v8::internal::Heap::AllocateRaw+0x207 0017d894 61b13cc2 0017d8c0 00000010 00000000 chrome_child!v8::internal::Heap::AllocateFillerObject+0x1e 0017d8c4 61d09a66 0017d900 00000010 00000000 chrome_child!v8::internal::Factory::NewFillerObject+0x22 0017d8f0 61d0475c 00000002 0017d980 00000002 chrome_child!v8::internal::Runtime_UnwindAndFindExceptionHandler+0x2f36 0017d910 14307a66 00000002 0017d980 00f01020 chrome_child!v8::internal::Runtime_AllocateInTargetSpace+0xcc WARNING: Frame IP not in any known module. Following frames may be wrong. 0017d974 34239880 00000004 00000020 00000c2a 0x14307a66 0017daec 14307355 2c206151 2c206161 2c206171 0x34239880 0017db20 34231ce6 2c206151 2c206161 2c206171 0x14307355 0017dc44 61b07963 0d2041a1 332e5175 356c27d9 0x34231ce6 0017dca4 7779e023 00f01020 00f2fae8 00000000 chrome_child!v8::internal::StackGuard::ThreadLocal::Initialize+0x3a3 0017dccc 61b071c9 0017dd78 00f01020 00000000 ntdll!RtlFreeHeap+0x7e 0017dcfc 6180a623 0017dd78 00f01020 00f2eb24 chrome_child!v8::internal::Execution::Call+0x89 0017dd98 62a173dc 0017dde0 00f2eb54 46b419e8 chrome_child!v8::Script::Run+0x273 0017ddfc 62a19a99 0017de58 00f01020 00f2eb24 chrome_child!blink::V8ScriptRunner::runCompiledScript+0x1b1 0017de68 62a19861 0017dec4 00f2eaf8 0017e084 chrome_child!blink::ScriptController::executeScriptAndReturnValue+0x1bd 0017deb0 62a1a041 0017dee4 0017e084 00000001 chrome_child!blink::ScriptController::evaluateScriptInMainWorld+0xa4 0017ded8 63e1886b 0017e084 00000001 00000001 chrome_child!blink::ScriptController::executeScriptInMainWorld+0x29 0017e000 63e18a67 0017e084 2126a1f8 58750738 chrome_child!blink::ScriptLoader::doExecuteScript+0x678 0017e01c 63e19b8f 0017e084 5874e0f0 39334748 chrome_child!blink::ScriptLoader::executeScript+0x1b 0017e15c 62e6cd68 3ea11550 3e8b8648 652869ad chrome_child!blink::ScriptLoader::prepareScript+0x454 0017e33c 62e6bc8b 58750738 0017e37c 390a56c0 chrome_child!blink::HTMLScriptRunner::runScript+0xf5 0017e36c 62e4e1d5 2126bf88 0017e37c 00000017 chrome_child!blink::HTMLScriptRunner::execute+0xb7 0017e384 62e4d75d 3fc4f1d8 3fc4f3f8 00000000 chrome_child!blink::HTMLDocumentParser::runScriptsForPausedTreeBuilder+0x64 0017e530 62e4d9e4 00000000 00ec3338 39334710 chrome_child!blink::HTMLDocumentParser::processTokenizedChunkFromBackgroundParser+0x4f6 0017e568 629ff07b 07b8d230 00ece140 0017e7b0 chrome_child!blink::HTMLDocumentParser::pumpPendingSpeculations+0x20b 0017e630 6290d93a 0017e648 628d8d96 3933cc70 chrome_child!WTF::Function<void __cdecl(void),1>::operator()+0x64 0017e638 628d8d96 3933cc70 3933cc70 0017e65c chrome_child!blink::scheduler::WebTaskRunnerImpl::runTask+0xb 0017e648 628da48f 057a3088 057a308c 057a3078 chrome_child!base::internal::Invoker<base::internal::BindState<void (__cdecl*)(std::unique_ptr<webcrypto::`anonymous namespace'::DeriveBitsState,std::default_delete<webcrypto::`anonymous namespace'::DeriveBitsState> >),base::internal::PassedWrapper<std::unique_ptr<webcrypto::`anonymous namespace'::DeriveBitsState,std::default_delete<webcrypto::`anonymous namespace'::DeriveBitsState> > > >,void __cdecl(void)>::RunImpl<void (__cdecl*const &)(std::unique_ptr<webcrypto::`anonymous namespace'::DeriveBitsState,std::default_delete<webcrypto::`anonymous namespace'::DeriveBitsState> >),std::tuple<base::internal::PassedWrapper<std::unique_ptr<webcrypto::`anonymous namespace'::DeriveBitsState,std::default_delete<webcrypto::`anonymous namespace'::DeriveBitsState> > > > const &,0>+0x1f 0017e65c 62097248 057a3078 00000001 0188a48a chrome_child!base::internal::Invoker<base::internal::BindState<void (__cdecl*)(std::unique_ptr<webcrypto::`anonymous namespace'::DeriveBitsState,std::default_delete<webcrypto::`anonymous namespace'::DeriveBitsState> >),base::internal::PassedWrapper<std::unique_ptr<webcrypto::`anonymous namespace'::DeriveBitsState,std::default_delete<webcrypto::`anonymous namespace'::DeriveBitsState> > > >,void __cdecl(void)>::Run+0x16 0017e6c4 6296fea7 6442e63c 652869ab 0017e864 chrome_child!base::debug::TaskAnnotator::RunTask+0x118 0017e858 6296f40f 00000000 0017f134 6442e498 chrome_child!blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue+0x2d0 0017e9c8 6296e6ab 00000000 00000000 00000005 chrome_child!blink::scheduler::TaskQueueManager::DoWork+0x1ce 0017e9dc 6296e6f1 6296f241 00000000 00ed13d0 chrome_child!base::internal::FunctorTraits<void (__thiscall blink::scheduler::TaskQueueManager::*)(base::TimeTicks,bool),void>::Invoke<base::WeakPtr<blink::scheduler::TaskQueueManager> const &,base::TimeTicks const &,bool const &>+0x22 0017e9f8 6296e70d 00ed13b8 00ed13d0 00ed13c8 chrome_child!base::internal::InvokeHelper<1,void>::MakeItSo<void (__thiscall blink::scheduler::TaskQueueManager::*const &)(base::TimeTicks,bool),base::WeakPtr<blink::scheduler::TaskQueueManager> const &,base::TimeTicks const &,bool const &>+0x25 0017ea10 629701a0 00ed13b8 00ed13c0 00ed13a8 chrome_child!base::internal::Invoker<base::internal::BindState<void (__thiscall blink::scheduler::TaskQueueManager::*)(base::TimeTicks,bool),base::WeakPtr<blink::scheduler::TaskQueueManager>,base::TimeTicks,bool>,void __cdecl(void)>::RunImpl<void (__thiscall blink::scheduler::TaskQueueManager::*const &)(base::TimeTicks,bool),std::tuple<base::WeakPtr<blink::scheduler::TaskQueueManager>,base::TimeTicks,bool> const &,0,1,2>+0x17 0017ea24 62097248 00ed13a8 00000000 0188a48a chrome_child!base::internal::Invoker<base::internal::BindState<void (__thiscall blink::scheduler::TaskQueueManager::*)(base::TimeTicks,bool),base::WeakPtr<blink::scheduler::TaskQueueManager>,base::TimeTicks,bool>,void __cdecl(void)>::Run+0x16 0017ea8c 6205d30c 641457c8 652869ab 00ece2a8 chrome_child!base::debug::TaskAnnotator::RunTask+0x118 0017f0bc 6205c333 0017f134 00eb8480 00ece2a8 chrome_child!base::MessageLoop::RunTask+0x4cc 0017f178 62099c10 00000000 00ece2a8 00000000 chrome_child!base::MessageLoop::DoWork+0x263 0017f260 6205ce31 00ece2a8 0017f4c8 63fc4cc0 chrome_child!base::MessagePumpDefault::Run+0x1a0 0017f48c 6206c839 64c12a10 01869d9c 00000000 chrome_child!base::MessageLoop::RunHandler+0x131 0017f4b4 63460812 00e9a818 00000003 00e9b140 chrome_child!base::RunLoop::Run+0x29
,
Oct 30 2016
BTW, I'm not sure how frequent this failure is. It doesn't look that prevalent in the chromium-try-flakes occurrences from Issue 619264 : https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyMAsSBUZsYWtlIiV3ZWJnbDJfY29uZm9ybWFuY2VfdGVzdHMgKHdpdGggcGF0Y2gpDA Scanning through the recent failures I've only found these two so far: https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_optional_gpu_tests_rel/builds/3517 https://chromium-swarm.appspot.com/user/task/3223b80ba88feb10 https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_optional_gpu_tests_rel/builds/4382 https://chromium-swarm.appspot.com/user/task/321f9e454d5a9010
,
Oct 31 2016
I think I know what's going on here. At FreeList::Allocate we have top != null and limit == null, which causes overflow in CHECK(static_cast<size_t>(owner_->limit() - owner_->top()) < size_in_bytes) The following scenario can lead to this state: 1. In crankshafted code we do deferred folded allocation in the old space (https://cs.chromium.org/chromium/src/v8/src/crankshaft/x64/lithium-codegen-x64.cc?rcl=0&l=5048) 2. During the runtime allocation we start incremental marking. 3. At the end of the allocation we do incremental marking step via allocation observer, which finishes sweeping and starts marking. (https://cs.chromium.org/chromium/src/v8/src/heap/spaces-inl.h?rcl=0&l=511) 4. When starting marking we collect evacuation candidate, which chooses a page that contains top and limit as evacuation candidate. 5. We set top and limit to null and return the newly allocated object to the generated code (https://cs.chromium.org/chromium/src/v8/src/heap/mark-compact.cc?rcl=0&l=293) 6. The generated code sets the top to start of the object: https://cs.chromium.org/chromium/src/v8/src/crankshaft/x64/lithium-codegen-x64.cc?rcl=0&l=5070 7. We have top != null and limit == null.
,
Oct 31 2016
There are several fixes possible. I think the best solution would be to decouple incremental marker from the allocation mechanism by forbidding the marker to change the linear allocation area. In this case we wouldn't be able to compact one page per space but the code would be more robust. I will discuss this tradeoff with other GC team members. Since they are OOO today and tomorrow is a public holiday, I will submit a fix on Wednesday.
,
Nov 1 2016
Awesome diagnosis Ulan! Thanks for thinking this through so carefully.
,
Nov 2 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/bb24b91f1533decd1b586ef366efa10f6e5e4d75 commit bb24b91f1533decd1b586ef366efa10f6e5e4d75 Author: ulan <ulan@chromium.org> Date: Wed Nov 02 14:13:27 2016 [heap] Invoke incremental marking step before allocation. This ensures that the newly allocated object immediatly precedes the linear allocation area, which is needed for allocation folding. For more info see: https://bugs.chromium.org/p/chromium/issues/detail?id=659165#c13 BUG= chromium:659165 Review-Url: https://codereview.chromium.org/2464393002 Cr-Commit-Position: refs/heads/master@{#40704} [modify] https://crrev.com/bb24b91f1533decd1b586ef366efa10f6e5e4d75/src/heap/incremental-marking.cc [modify] https://crrev.com/bb24b91f1533decd1b586ef366efa10f6e5e4d75/src/heap/incremental-marking.h [modify] https://crrev.com/bb24b91f1533decd1b586ef366efa10f6e5e4d75/src/heap/spaces.cc
,
Nov 2 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/bb24b91f1533decd1b586ef366efa10f6e5e4d75 commit bb24b91f1533decd1b586ef366efa10f6e5e4d75 Author: ulan <ulan@chromium.org> Date: Wed Nov 02 14:13:27 2016 [heap] Invoke incremental marking step before allocation. This ensures that the newly allocated object immediatly precedes the linear allocation area, which is needed for allocation folding. For more info see: https://bugs.chromium.org/p/chromium/issues/detail?id=659165#c13 BUG= chromium:659165 Review-Url: https://codereview.chromium.org/2464393002 Cr-Commit-Position: refs/heads/master@{#40704} [modify] https://crrev.com/bb24b91f1533decd1b586ef366efa10f6e5e4d75/src/heap/incremental-marking.cc [modify] https://crrev.com/bb24b91f1533decd1b586ef366efa10f6e5e4d75/src/heap/incremental-marking.h [modify] https://crrev.com/bb24b91f1533decd1b586ef366efa10f6e5e4d75/src/heap/spaces.cc
,
Nov 3 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/8f85aba4eafca816ece83cfed49635e277f0d188 commit 8f85aba4eafca816ece83cfed49635e277f0d188 Author: ulan <ulan@chromium.org> Date: Thu Nov 03 09:56:46 2016 Revert of [heap] Invoke incremental marking step before allocation. (patchset #1 id:1 of https://codereview.chromium.org/2464393002/ ) Reason for revert: Performance regression on Octane and V8 runtime stats. Original issue's description: > [heap] Invoke incremental marking step before allocation. > > This ensures that the newly allocated object immediatly precedes the > linear allocation area, which is needed for allocation folding. > > For more info see: > https://bugs.chromium.org/p/chromium/issues/detail?id=659165#c13 > > BUG= chromium:659165 TBR=hpayer@chromium.org,mlippautz@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= chromium:659165 Review-Url: https://codereview.chromium.org/2472043002 Cr-Commit-Position: refs/heads/master@{#40713} [modify] https://crrev.com/8f85aba4eafca816ece83cfed49635e277f0d188/src/heap/incremental-marking.cc [modify] https://crrev.com/8f85aba4eafca816ece83cfed49635e277f0d188/src/heap/incremental-marking.h [modify] https://crrev.com/8f85aba4eafca816ece83cfed49635e277f0d188/src/heap/spaces.cc
,
Nov 3 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/e7aa6f91b3411f47a429e22b2e20635426ad3836 commit e7aa6f91b3411f47a429e22b2e20635426ad3836 Author: ulan <ulan@chromium.org> Date: Thu Nov 03 12:12:38 2016 [heap] Exclude the owner of the linear allocation area from evacuation. This ensures that incremental marking step does not change the top and limit pointers of the old space, which is needed for allocation folding. For more info see: https://bugs.chromium.org/p/chromium/issues/detail?id=659165#c13 BUG= chromium:659165 Review-Url: https://codereview.chromium.org/2469273002 Cr-Commit-Position: refs/heads/master@{#40720} [modify] https://crrev.com/e7aa6f91b3411f47a429e22b2e20635426ad3836/src/heap/mark-compact.cc [modify] https://crrev.com/e7aa6f91b3411f47a429e22b2e20635426ad3836/src/heap/spaces.cc [modify] https://crrev.com/e7aa6f91b3411f47a429e22b2e20635426ad3836/src/heap/spaces.h [modify] https://crrev.com/e7aa6f91b3411f47a429e22b2e20635426ad3836/test/cctest/heap/heap-utils.cc [modify] https://crrev.com/e7aa6f91b3411f47a429e22b2e20635426ad3836/test/cctest/heap/heap-utils.h [modify] https://crrev.com/e7aa6f91b3411f47a429e22b2e20635426ad3836/test/cctest/heap/test-array-buffer-tracker.cc [modify] https://crrev.com/e7aa6f91b3411f47a429e22b2e20635426ad3836/test/cctest/heap/test-heap.cc [modify] https://crrev.com/e7aa6f91b3411f47a429e22b2e20635426ad3836/test/cctest/test-unboxed-doubles.cc
,
Nov 8 2016
#19 seems working, don't see the crash in recent bot runs.
,
Nov 8 2016
Fantastic. Thanks Ulan.
,
Nov 30 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by ynovikov@chromium.org
, Oct 25 2016Status: Available (was: Untriaged)