Still happens
https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28NVIDIA%29/builds/27951

Increasing to P1. This looks like a recent regression.

Assigning to current sheriff.

We changed how sweeping starts and ends in https://codereview.chromium.org/2445283003/ yesterday.

I'll keep an eye on the buildbot to see if the assert reproduces with the new code.

Still happens
https://build.chromium.org/p/chromium.gpu.fyi/builders/Win8%20Release%20%28NVIDIA%29/builds/24999

WebglConformance_deqp_functional_gles3_texturespecification_basic_teximage2d_2d_00 (gpu_tests.webgl_conformance_integration_test.WebGLConformanceIntegrationTest) ... 

#
# Fatal error in e:\b\c\b\win\src\v8\src\heap\mark-compact.cc, line 649
# Check failed: p->SweepingDone().
#
Error initializing symbols (87).  Dumping unresolved backtrace:
	6B1310F0
	6A493F2B
	6A49C76E
	6A48A9CA
	6A487DA6
	6A486F03
	6A9C1878
	6B26028F
	6B25F7C6
	6B25EA43
	6B25EA89
	6B25EAA5
	6B260568
	6A9C1878
	6A986DDC
	6A985D65
	6A9C41C0
	6A986901
	6A996679
	6BD84838
	6A93A9A4
	6A93A8C3
	6A939D44
	69F994EE
	010D4C9E
	010D2954
	0111CF58
	77387C04
	777FAD1F
	777FACEA
Backtrace:
	(No symbol) [0x00000000]
	v8::base::OS::Abort [0x6B12992D+13]
	V8_Fatal [0x6B12944C+124]
	v8::internal::MarkCompactCollector::CollectEvacuationCandidates [0x6A493F2B+315]
	v8::internal::MarkCompactCollector::StartCompaction [0x6A49C76E+62]
	v8::internal::IncrementalMarking::StartMarking [0x6A48A669+105]
	v8::internal::IncrementalMarking::Step [0x6A48A9CA+490]
	v8::internal::IncrementalMarking::AdvanceIncrementalMarking [0x6A487DA6+150]
	v8::internal::IncrementalMarkingJob::Task::RunInternal [0x6A486F03+195]
	base::debug::TaskAnnotator::RunTask [0x6A9C1878+280]
	blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue [0x6B26028F+715]
	blink::scheduler::TaskQueueManager::DoWork [0x6B25F7C6+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 &> [0x6B25EA43+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 &> [0x6B25EA89+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 [0x6B25EAA5+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 [0x6B260568+22]
	base::debug::TaskAnnotator::RunTask [0x6A9C1878+280]
	base::MessageLoop::RunTask [0x6A986DDC+1228]
	base::MessageLoop::DoWork [0x6A985D65+597]
	base::MessagePumpDefault::Run [0x6A9C41C0+416]
	base::MessageLoop::RunHandler [0x6A986901+305]
	base::RunLoop::Run [0x6A996679+41]
	content::RendererMain [0x6BD84838+486]
	content::RunNamedProcessTypeMain [0x6A93A9A4+176]
	content::ContentMainRunnerImpl::Run [0x6A93A8C3+274]
	content::ContentMain [0x6A939D44+35]
	ChromeMain [0x69F994EE+158]
	MainDllLoader::Launch [0x010D4C9E+527]
	wWinMain [0x010D2954+342]
	__scrt_common_main_seh [0x0111CF58+246] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253)
	BaseThreadInitThunk [0x77387C04+36]
	RtlInitializeExceptionChain [0x777FAD1F+143]
	RtlInitializeExceptionChain [0x777FACEA+90]

https://codereview.chromium.org/2445283003/
was rolled in
https://build.chromium.org/p/chromium.gpu.fyi/builders/Win8%20Release%20%28NVIDIA%29/builds/24979
btw, so this is definitely still happening

Cannot reproduce locally.

Doing trybot debugging with more strick checks in: 

https://codereview.chromium.org/2462613002/

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/b0b1d7a9e6e199978c2c92aebcc592e720743de2

commit b0b1d7a9e6e199978c2c92aebcc592e720743de2
Author: ulan <ulan@chromium.org>
Date: Fri Oct 28 16:53:13 2016

[heap] Check that sweeping is completed when collecting evacuation
candidates.

BUG= chromium:650314 

Review-Url: https://codereview.chromium.org/2459003002
Cr-Commit-Position: refs/heads/master@{#40651}

[modify] https://crrev.com/b0b1d7a9e6e199978c2c92aebcc592e720743de2/src/heap/mark-compact.cc

Seems like the new DCHECKs don't trigger.
https://build.chromium.org/p/chromium.gpu.fyi/builders/Mac%2010.10%20Release%20%28Intel%29/builds/18923/steps/webgl2_conformance_tests%20on%20Intel%20GPU%20on%20Mac%20on%20Mac-10.10/logs/stdio

Thanks, ynovikov@!

New DCHECKs not firing eliminates one hypothesis. Investigation continues.

Is the bot in #11 running with dchecks on?

#13: Yes, it is. Look at a recent build from:
https://build.chromium.org/p/chromium.gpu.fyi/builders/Mac%2010.10%20Release%20%28Intel%29/

the parent builder is "GPU Mac Builder" (just noticed this is stuck, filed Issue 663464 about it):
https://build.chromium.org/p/chromium.gpu.fyi/builders/GPU%20Mac%20Builder

Look at the stdio for "generate build files" from any build:
https://build.chromium.org/p/chromium.gpu.fyi/builders/GPU%20Mac%20Builder/builds/75864/steps/generate_build_files/logs/stdio

Note that:
dcheck_always_on = true

is set in the GN configuration.

Issue 663660 has been merged into this issue.

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Thanks, Ken. Good to know how to check the flags in future :)

I found one scenario that can lead to this assert:
https://codereview.chromium.org/2484153004/

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/b621987195cdb1b2031809d9f10aff3005190161

commit b621987195cdb1b2031809d9f10aff3005190161
Author: ulan <ulan@chromium.org>
Date: Wed Nov 09 12:14:15 2016

[heap] Ensure that the sweeper does not lose unswept pages.

This fixes a race between the sweeper and the array buffer tracker
that causes the sweeper to skip unswept pages.

The scenario:
1. Mark-compact GC adds page p to the sweeping_list_ of the sweeper.
2. GC finishes, the main thread starts executinng JS.
3. The main thread takes p->mutex to unregister an array buffer.
4. A sweeper thread removes p from the sweeping_list_ and tries to
   take p->mutex. The try fails. The sweeper drops p and continues
   to the next page.
5. During selection of evacuation candidate in the next GC we hit
   page->SweepingDone() assert.

BUG= chromium:650314 

Review-Url: https://codereview.chromium.org/2484153004
Cr-Commit-Position: refs/heads/master@{#40857}

[modify] https://crrev.com/b621987195cdb1b2031809d9f10aff3005190161/src/heap/mark-compact.cc

Ulan, this is just awesome! Thank you for tracking down this nasty race condition!