Flaky OS::Allocate in test-lockers |
|||
Issue description
Just had this flake locally while running all tests
=== cctest/test-lockers/ExtensionsRegistration ===
#
# Fatal error in ../../src/base/platform/platform-win32.cc, line 832
# Debug check failed: base == aligned_base (00000000 vs. 0EB80000).
#
==== C stack trace ===============================
v8::base::debug::StackTrace::StackTrace [0x68E73263+19] (D:\src\v8\v8\src\base\debug\stack_trace_win.cc:177)
v8::platform::`anonymous namespace'::PrintStackTrace [0x735462C2+34] (D:\src\v8\v8\src\libplatform\default-platform.cc:27)
V8_Fatal [0x68E6A77B+107] (D:\src\v8\v8\src\base\logging.cc:135)
v8::base::`anonymous namespace'::DefaultDcheckHandler [0x68E6A4E6+22]
v8::base::OS::Allocate [0x68E75E22+1554] (D:\src\v8\v8\src\base\platform\platform-win32.cc:832)
v8::base::PageAllocator::AllocatePages [0x68E6B864+20] (D:\src\v8\v8\src\base\page-allocator.cc:43)
v8::internal::AllocatePages [0x00FA645D+125] (D:\src\v8\v8\src\allocation.cc:150)
v8::internal::AlignedAllocVirtualMemory [0x00FA6E6B+75] (D:\src\v8\v8\src\allocation.cc:289)
v8::internal::MemoryAllocator::AllocateAlignedMemory [0x0148BAD2+66] (D:\src\v8\v8\src\heap\spaces.cc:454)
v8::internal::MemoryAllocator::AllocateChunk [0x0148CC29+393] (D:\src\v8\v8\src\heap\spaces.cc:794)
v8::internal::PagedSpace::Expand [0x0148FCAC+76] (D:\src\v8\v8\src\heap\spaces.cc:1580)
v8::internal::PagedSpace::RawSlowRefillLinearAllocationArea [0x0149595E+238] (D:\src\v8\v8\src\heap\spaces.cc:3084)
v8::internal::PagedSpace::SlowRefillLinearAllocationArea [0x014957EF+127] (D:\src\v8\v8\src\heap\spaces.cc:3032)
v8::internal::Heap::ReserveSpace [0x0142F8BC+620] (D:\src\v8\v8\src\heap\heap.cc:1549)
v8::internal::DefaultDeserializerAllocator::ReserveSpace [0x0178E949+425] (D:\src\v8\v8\src\snapshot\default-deserializer-allocator.cc:180)
v8::internal::StartupDeserializer::DeserializeInto [0x017A768C+60] (D:\src\v8\v8\src\snapshot\startup-deserializer.cc:21)
v8::internal::Isolate::Init [0x015224DF+7695] (D:\src\v8\v8\src\isolate.cc:3083)
v8::internal::Snapshot::Initialize [0x017A47E0+304] (D:\src\v8\v8\src\snapshot\snapshot-common.cc:53)
v8::IsolateNewImpl [0x00FF6A94+404] (D:\src\v8\v8\src\api.cc:8407)
v8::Isolate::New [0x00FF68F7+39] (D:\src\v8\v8\src\api.cc:8354)
v8::internal::test_lockers::IsolateGenesisThread::Run [0x00D56E92+98] (D:\src\v8\v8\test\cctest\test-lockers.cc:921)
v8::internal::test_lockers::JoinableThread::ThreadWithSemaphore::Run [0x00D55DFE+14] (D:\src\v8\v8\test\cctest\test-lockers.cc:388)
v8::base::ThreadEntry [0x68E7718A+26] (D:\src\v8\v8\src\base\platform\platform-win32.cc:1251)
o__CIpow [0x7603D70F+79]
BaseThreadInitThunk [0x76D762C4+36]
RtlSubscribeWnfStateChangeNotification [0x77780F79+1081]
RtlSubscribeWnfStateChangeNotification [0x77780F44+1028]
Command: D:\src\v8\v8\out.gn\Release\cctest.exe test-lockers/ExtensionsRegistration --random-seed=-1320921544 --nohard-abort
,
Feb 19 2018
I guess that DCHECK should rather be DCHECK_IMPLIES(base, base == aligned_base); Bill?
,
Feb 19 2018
Hmmm, I would have guessed it's very rare that we'd lose 3 mappings in a row due to a race. It makes me wonder if it's possible to get into a pattern where we would never get the mapping. If so, that would mean Chromium's page allocator can hang. Another solution is to increase the number of attempts. That would mean the test is still slightly flaky but less so. Say 5 or 6? Or make it an infinite loop - that's what we now do for V8 in Chromium. Changing the DCHECK would be another solution, though the signs are that we should be able to allocate memory in this case.
,
Feb 20 2018
I am fine with increasing the retries a bit. IIUC, the DCHECK is still off as it is actually valid to OOM here, even with the scenario where the second allocation races with something else, no?
,
Feb 20 2018
Yes, returning nullptr here is valid since we don't loop infinitely. Let's change the DCHECK and leave kMaxAttempts as it is. I'm curious as to why the flakes happened. I'll try to reproduce this locally. gab@ any hints?
,
Feb 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/f812038c0662c2b4bbaa652213753e8d0ca03b28 commit f812038c0662c2b4bbaa652213753e8d0ca03b28 Author: Bill Budge <bbudge@chromium.org> Date: Tue Feb 20 19:14:55 2018 [Memory] Fix OS::Allocate on Windows / Cygwin. - Changes assert to reflect that we might exceed the number of attempts to allocate a padded memory region while attempting to get an aligned allocation and return null instead. Bug: chromium:813587 Change-Id: I0e225f50b7a64a2f2a72de15322525574445efbd Reviewed-on: https://chromium-review.googlesource.com/926968 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#51401} [modify] https://crrev.com/f812038c0662c2b4bbaa652213753e8d0ca03b28/src/base/platform/platform-cygwin.cc [modify] https://crrev.com/f812038c0662c2b4bbaa652213753e8d0ca03b28/src/base/platform/platform-win32.cc
,
Feb 20 2018
No hints really, I was just running all v8 tests in a release+component+dcheck_always_on build when it occurred once. Hence filled this but it never repro'ed. Le mar. 20 févr. 2018 20 h 15, bugdroid1 via monorail < monorail+v2.3275348242@chromium.org> a écrit : |
|||
►
Sign in to add a comment |
|||
Comment 1 by gab@chromium.org
, Feb 19 2018