Raising to P1 until this is triaged.

This is happening on Windows and Linux too and is affecting the commit queue:
https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyLwsSBUZsYWtlIiR3ZWJnbF9jb25mb3JtYW5jZV90ZXN0cyAod2l0aCBwYXRjaCkM

A few example builds all hitting the same DCHECK in WebglConformance.conformance_misc_bad_arguments_test:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/239417
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/239415
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_rel_ng/builds/246838

This is urgent. Was there a recent change to the loader? If so it should be reverted until these assertion failures are understood.

Examining the recent try flakes:
https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyLwsSBUZsYWtlIiR3ZWJnbF9jb25mb3JtYW5jZV90ZXN0cyAod2l0aCBwYXRjaCkM

I can't find evidence of this failure before today, but at least the last 5 flakes in a row have been caused by this DCHECK.

cc yhirano as loading triager. Looks like this might be reproducible with a debugger.

Somehow the synchronous fetch is losing its priority, which should be set here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp?rcl=0&l=143

I looked through recent changes in the last 2 days and couldn't find an obvious culprit.

japhet@ points out that the most recent possibly relevant change was ~6 days ago:
https://chromium.googlesource.com/chromium/src/+/5b689eeb4cc9dc5636a8db73c79a2674a154e967

I'm not seeing evidence of this failure before today, but it seems clear that something has changed to trigger this DCHECK.

It looks like this flake isn't happening today, so...that's something?

The resource load priority logic is unnecessarily complicated, so I wrote a cleanup patch to see if we can refactor this bug away. https://codereview.chromium.org/2072613002/

Note: just found another flake:
https://chromium-swarm.appspot.com/user/task/2f9c4a7e8cfa2e11

[ RUN      ] WebglConformance.conformance_misc_bad_arguments_test
(INFO) 2016-06-24 10:37:41,746 cache_temperature.EnsurePageCacheTemperature:55  PageCacheTemperature: any
[3104:2980:0624/103741:FATAL:resourceloader.cpp(230)] Check failed: request.priority() == ResourceLoadPriorityHighest. 
Backtrace:
	base::debug::StackTrace::StackTrace [0x69601E87+23]
	logging::LogMessage::~LogMessage [0x695AA151+49]
	blink::ResourceLoader::requestSynchronously [0x690B1C73+176]
	blink::ResourceLoader::start [0x690B1EC6+201]
	blink::ResourceFetcher::startLoad [0x690AFE42+298]
	blink::ResourceFetcher::requestResource [0x690AF6AA+1565]
	blink::RawResource::fetch [0x690A1C13+128]
	blink::DocumentThreadableLoader::loadRequest [0x69167EF0+597]
	blink::DocumentThreadableLoader::dispatchInitialRequest [0x691673A0+56]
	blink::DocumentThreadableLoader::start [0x6916957C+1025]
	blink::XMLHttpRequest::createRequest [0x6921925A+1199]
	blink::XMLHttpRequest::send [0x6921B9F5+399]
	blink::XMLHttpRequest::send [0x6921BF3C+51]
	blink::Iterable<unsigned int,blink::Node *>::EntrySelector::select [0x68C1DBD4+397]
	v8::internal::FunctionCallbackArguments::Call [0x683BD224+116]
	v8::internal::IncrementalStringBuilder::Append<unsigned char,unsigned short> [0x6841A9DE+1902]
	v8::internal::Builtins::BooleanConstructor_ConstructStub [0x684261E8+34504]
	v8::internal::Isolate::typed_array_prototype [0x68418C00+4272]

Backtrace:
	base::debug::BreakDebugger [0x69606E09+9]
	logging::InitChromeLogging [0x695A73B3+737]
	logging::LogMessage::~LogMessage [0x695AA2E7+455]
	blink::ResourceLoader::requestSynchronously [0x690B1C73+176]
	blink::ResourceLoader::start [0x690B1EC6+201]
	blink::ResourceFetcher::startLoad [0x690AFE42+298]
	blink::ResourceFetcher::requestResource [0x690AF6AA+1565]
	blink::RawResource::fetch [0x690A1C13+128]
	blink::DocumentThreadableLoader::loadRequest [0x69167EF0+597]
	blink::DocumentThreadableLoader::dispatchInitialRequest [0x691673A0+56]
	blink::DocumentThreadableLoader::start [0x6916957C+1025]
	blink::XMLHttpRequest::createRequest [0x6921925A+1199]
	blink::XMLHttpRequest::send [0x6921B9F5+399]
	blink::XMLHttpRequest::send [0x6921BF3C+51]
	blink::Iterable<unsigned int,blink::Node *>::EntrySelector::select [0x68C1DBD4+397]
	v8::internal::FunctionCallbackArguments::Call [0x683BD224+116]
	v8::internal::IncrementalStringBuilder::Append<unsigned char,unsigned short> [0x6841A9DE+1902]
	v8::internal::Builtins::BooleanConstructor_ConstructStub [0x684261E8+34504]
	v8::internal::Isolate::typed_array_prototype [0x68418C00+4272]
	(No symbol) [0x3E20A0DE]
	(No symbol) [0x21A3BC6D]
	v8::internal::StackGuard::ThreadLocal::Initialize [0x6862F34B+523]
	WTF::StringImpl::operator delete [0x69CB297C+1303]
	blink::V8ScriptRunner::runCompiledScript [0x68C02F66+445]
	blink::V8ScriptRunner::compileScript [0x68C02542+200]

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

commit fd0671f01914a4f5e74620e75f673f213d302823
Author: japhet <japhet@chromium.org>
Date: Fri Aug 05 23:47:02 2016

Make ResourceLoadPriority calculation simpler

* Don't keep a separate ResourceLoadPriority value on
  FetchRequest, just use ResourceRequest::m_priority.
* Make a bit more use of FetchRequest::LazyLoad for cases
  like preloads where the priority of a request should be
  very low.
* ResourceFetcher::loadPriority() shouldn't blindly trust the
  priority given by a caller, and instead takes the max of
  the provided priority and the priority it calculates.
* Add a helper to FetchRequest to make a request synchronous,
  so callers don't need to manually flag the request as
  Highest priority.

This may or may not fix a case where synchronous requests are
incorrectly and flakily being given a priority lower than
Highest.

BUG= 620334 

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

[modify] https://crrev.com/fd0671f01914a4f5e74620e75f673f213d302823/third_party/WebKit/Source/core/fetch/FetchRequest.cpp
[modify] https://crrev.com/fd0671f01914a4f5e74620e75f673f213d302823/third_party/WebKit/Source/core/fetch/FetchRequest.h
[modify] https://crrev.com/fd0671f01914a4f5e74620e75f673f213d302823/third_party/WebKit/Source/core/fetch/RawResource.cpp
[modify] https://crrev.com/fd0671f01914a4f5e74620e75f673f213d302823/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp
[modify] https://crrev.com/fd0671f01914a4f5e74620e75f673f213d302823/third_party/WebKit/Source/core/fetch/ResourceFetcher.h
[modify] https://crrev.com/fd0671f01914a4f5e74620e75f673f213d302823/third_party/WebKit/Source/core/fetch/XSLStyleSheetResource.cpp
[modify] https://crrev.com/fd0671f01914a4f5e74620e75f673f213d302823/third_party/WebKit/Source/core/html/LinkResource.cpp
[modify] https://crrev.com/fd0671f01914a4f5e74620e75f673f213d302823/third_party/WebKit/Source/core/loader/LinkLoader.cpp

Gentle ping.  Does it look like #10 fixed this issue?  If still P1 could you please assign a milestone?

Thanks Nate for driving this to completion!