New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 606694 link

Starred by 1 user
Status: WontFix
Owner:
keishi@chromium.org
Closed: Jun 2016
Cc:
japhet@chromium.org
█ sigbjo...@opera.com
haraken@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocking:
issue 596622



Sign in to add a comment

ASSERTION FAILED: !m_heapDoesNotContainCache->lookup(address) in XMLHttpRequest::createRequest

Project Member Reported by kbr@chromium.org, Apr 26 2016 
https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/211124

A random webgl_conformance_test failed with the following assertion failure and stack trace:

ASSERTION FAILED: !m_heapDoesNotContainCache->lookup(address)
e:\b\build\slave\win\build\src\third_party\webkit\source\platform\heap\heap.cpp(334) : unsigned char *__thiscall blink::ThreadHeap::checkAndMarkPointer(class blink::Visitor *,unsigned char *)
Backtrace:
	blink::ThreadHeap::checkAndMarkPointer [0x61D835FB+251]
	blink::ThreadState::visitStack [0x61D79BBA+74]
	blink::ThreadHeap::visitStackRoots [0x61D866EF+399]
	blink::ThreadHeap::collectGarbage [0x61D83999+537]
	blink::ThreadState::scheduleGCIfNeeded [0x61D76FDB+331]
	blink::NormalPageArena::outOfLineAllocate [0x61D7ED09+313]
	blink::NormalPageArena::allocateObject [0x61D5D2B3+227]
	blink::ThreadHeap::allocateOnArenaIndex [0x61D5E98E+174]
	blink::RawResource::RawResourceFactory::create [0x627957E6+38]
	blink::ResourceFetcher::createResourceForLoading [0x625E0A5F+271]
	blink::ResourceFetcher::requestResource [0x625E4A8A+1242]
	blink::RawResource::fetch [0x62795B61+161]
	blink::DocumentThreadableLoader::loadRequest [0x6262B34F+591]
	blink::DocumentThreadableLoader::start [0x6262CEF6+1542]
	blink::XMLHttpRequest::createRequest [0x628629B4+1636]
	blink::XMLHttpRequest::send [0x62865E56+550]
	blink::XMLHttpRequest::send [0x62866564+52]
	blink::Iterable<unsigned int,blink::Node *>::EntrySelector::select [0x62C3D108+648]
	v8::internal::FunctionCallbackArguments::Call [0x63E5AA33+67]
	v8::internal::AllocationTracker::functionInfoIndexForVMState [0x63CB999F+10447]
	v8::internal::Builtins::BooleanConstructor_ConstructStub [0x63CC31F5+28661]
	v8::internal::AllocationTracker::functionInfoIndexForVMState [0x63CB7CB0+3040]
	(No symbol) [0x1B70B77E]
	(No symbol) [0x0CFB9C4D]
	(No symbol) [0x0CFB98CE]
	(No symbol) [0x0CFB97D4]
	(No symbol) [0x0CFB90BA]
	(No symbol) [0x0CFB8E8B]
	v8::internal::StackGuard::ThreadLocal::Initialize [0x63EE5F23+467]
	v8::internal::Execution::Call [0x63EE5871+449]
	v8::Function::Call [0x61E1B52B+459]
	blink::V8ScriptRunner::callFunction [0x62C2A88F+479]
	blink::ScriptController::callFunction [0x62B4C150+112]
	blink::V8EventListener::callListenerFunction [0x62CADE4F+191]
	blink::V8AbstractEventListener::invokeEventHandler [0x62C9BAA2+242]
	blink::V8AbstractEventListener::handleEvent [0x62C9B90A+106]
	blink::V8AbstractEventListener::handleEvent [0x62C9B882+146]
	blink::EventTarget::fireEventListeners [0x623C6867+871]
	blink::EventTarget::fireEventListeners [0x623C69DD+237]
	blink::EventTarget::dispatchEventInternal [0x623C6336+38]
	blink::XMLHttpRequestProgressEventThrottle::dispatchReadyStateChangeEvent [0x628FB37B+155]
	blink::XMLHttpRequest::dispatchReadyStateChangeEvent [0x6286377F+303]
	blink::XMLHttpRequest::endLoading [0x62863B47+103]
	blink::XMLHttpRequest::didFinishLoadingInternal [0x6286304F+255]
	blink::XMLHttpRequest::didFinishLoading [0x62862F1E+206]
	blink::DocumentThreadableLoader::handleSuccessfulFinish [0x6262AC21+241]
	blink::DocumentThreadableLoader::notifyFinished [0x6262BE3B+187]
	blink::Resource::checkNotify [0x62779AA9+57]
	blink::Resource::finish [0x6277A345+101]
	blink::ResourceLoader::didFinishLoading [0x627F7525+181]
	content::WebURLLoaderImpl::Context::OnCompletedRequest [0x641C2CDC+268]
	content::WebURLLoaderImpl::RequestPeerImpl::OnCompletedRequest [0x641C2D10+32]
	content::ResourceDispatcher::OnRequestComplete [0x62D3EDDE+590]
	IPC::MessageT<ResourceMsg_RequestComplete_Meta,std::tuple<int,ResourceMsg_RequestCompleteData>,void>::Dispatch<content::ResourceDispatcher,content::ResourceDispatcher,void,void (__thiscall content::ResourceDispatcher::*)(int,ResourceMsg_RequestCompleteDat [0x62D3BEAD+221]
	content::ResourceDispatcher::DispatchMessageW [0x62D3DAAC+652]
	content::ResourceDispatcher::OnMessageReceived [0x62D3DFD5+373]
	content::ResourceSchedulingFilter::SetRequestIdTaskRunner [0x62D499B9+169]
	scheduler::WebTaskRunnerImpl::runTask [0x641E4FFB+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 [0x641F83FF+95]
	base::debug::TaskAnnotator::RunTask [0x617D7D17+247]
	scheduler::TaskQueueManager::ProcessTaskFromWorkQueue [0x641EC49D+1037]
	scheduler::TaskQueueManager::DoWork [0x641EB950+560]

I'm still triaging other new flakes so don't know how often this is showing up. Still, marking P1 since this has been seen on the commit queue.
stdout.txt
4.1 MB View Download

Comment 1 by haraken@chromium.org, Apr 26 2016

Cc: haraken@chromium.org
Owner: keishi@chromium.org
Hmm, this looks like a real bug. The ASSERT means that the address is contained in some valid page but the address is contained in HeapDoesNotContainCache (which is a negative cache to keep track of addresses that are not contained in any page).

keishi@: Would you mind taking a look at this?

Comment 2 by haraken@chromium.org, Apr 26 2016 

A good starting point would be to see if the crash is gone if you unconditionally flush the HeapDoesNotContainCache.

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/heap/ThreadState.cpp&sq=package:chromium&type=cs&l=923&rcl=1461640719

If the crash is gone, it would mean that m_shouldFlushHeapDoesNotContainCache is not set in places where it should be set.

Comment 3 by sigbjo...@opera.com, Apr 26 2016 

Can HeapDoesNotContainCache's encoding scheme give false positives?

Comment 4 by haraken@chromium.org, Apr 27 2016 

> Can HeapDoesNotContainCache's encoding scheme give false positives?

I don't think so.

I think it would be worth seeing if the crash is gone or not if we unconditionally flush the HeapDoesNotContainCache at every GC.

Comment 5 by sigbjo...@opera.com, Apr 27 2016 

Do you remember where HeapDoesNotContainCache's implementation & design comes from? The hashing scheme looks unusual.

Comment 6 by haraken@chromium.org, Apr 27 2016 

I don't think there was some deep discussion about the design. The cache is intended to be a simple two-way set associative negative cache.

Comment 7 by sigbjo...@opera.com, Apr 27 2016 

https://codereview.chromium.org/616483002/ was the CL for the latest larger change to it.

(I'm just trying to convince myself that if you end up scanning non-pointer values on the stack, hash collisions won't happen against other valid pointer values you encounter later.)

Comment 8 by keishi@chromium.org, Apr 28 2016 

I scanned through the build logs for the bot and I couldn't find the same crashes. It looks like this is a rare crash and I can't reproduce it.

Comment 9 by kbr@chromium.org, Apr 28 2016 

OK. Please try your best but if it's not reproducible then close this as WontFix. Thanks.

Comment 10 by vollick@chromium.org, May 11 2016 

Friendly ping. Any luck reproducing?

Comment 11 by kbr@chromium.org, Jun 7 2016

Status: WontFix (was: Assigned)
It sounds like this wasn't reproducible.
►

Sign in to add a comment