Stack Trace:

Thread 0 CRASHED [EXCEPTION_ACCESS_VIOLATION_READ @ 0x00000000 ] MAGIC SIGNATURE THREAD
0x1016ea23	(chrome_child.dll -htmlcanvaselement.cpp:877 )	blink::HTMLCanvasElement::buffer()
0x1016dc16	(chrome_child.dll -htmlcanvaselement.cpp:523 )	blink::HTMLCanvasElement::prepareSurfaceForPaintingIfNeeded()
0x10e70507	(chrome_child.dll -canvasrenderingcontext2d.cpp:513 )	blink::CanvasRenderingContext2D::didProcessTask()
0x0f8d5309	(chrome_child.dll -webthread_base.cc:30 )	scheduler::WebThreadBase::TaskObserverAdapter::DidProcessTask(base::PendingTask const &)
0x0f939e5d	(chrome_child.dll -task_queue_manager.cc:299 )	scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(scheduler::internal::WorkQueue *,scheduler::internal::TaskQueueImpl::Task *)
0x0f938e6c	(chrome_child.dll -task_queue_manager.cc:200 )	scheduler::TaskQueueManager::DoWork(base::TimeTicks,bool)
0x0f938d41	(chrome_child.dll -bind_internal.h:314 )	base::internal::InvokeHelper<1,void,base::internal::RunnableAdapter<void ( scheduler::TaskQueueManager::*)(base::TimeTicks,bool)> >::MakeItSo<base::WeakPtr<scheduler::TaskQueueManager>,base::TimeTicks const &,bool const &>(base::internal::RunnableAdapter<void ( scheduler::TaskQueueManager::*)(base::TimeTicks,bool)>,base::WeakPtr<scheduler::TaskQueueManager>,base::TimeTicks const &,bool const &)
0x0f938d00	(chrome_child.dll -bind_internal.h:354 )	base::internal::Invoker<base::IndexSequence<0,1,2>,base::internal::BindState<base::internal::RunnableAdapter<void ( scheduler::TaskQueueManager::*)(base::TimeTicks,bool)>,void ,base::WeakPtr<scheduler::TaskQueueManager>,base::TimeTicks,bool>,base::internal::InvokeHelper<1,void,base::internal::RunnableAdapter<void ( scheduler::TaskQueueManager::*)(base::TimeTicks,bool)> >,void >::Run(base::internal::BindStateBase *)
0x0f89b6a7	(chrome_child.dll -task_annotator.cc:51 )	base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask const &)
0x0f89b4ad	(chrome_child.dll -message_loop.cc:476 )	base::MessageLoop::RunTask(base::PendingTask const &)
0x0f89b2a0	(chrome_child.dll -message_loop.cc:597 )	base::MessageLoop::DoWork()
0x0f89d50b	(chrome_child.dll -message_pump_default.cc:33 )	base::MessagePumpDefault::Run(base::MessagePump::Delegate *)
0x0f89ac2a	(chrome_child.dll -run_loop.cc:35 )	base::RunLoop::Run()
0x0f89ab6a	(chrome_child.dll -message_loop.cc:293 )	base::MessageLoop::Run()
0x0f8ed35f	(chrome_child.dll -renderer_main.cc:219 )	content::RendererMain(content::MainFunctionParams const &)
0x0f892413	(chrome_child.dll -content_main_runner.cc:395 )	content::RunNamedProcessTypeMain(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,content::MainFunctionParams const &,content::ContentMainDelegate *)
0x0f89238f	(chrome_child.dll -content_main_runner.cc:764 )	content::ContentMainRunnerImpl::Run()
0x0f877d9d	(chrome_child.dll -content_main.cc:19 )	content::ContentMain(content::ContentMainParams const &)
0x0f877a79	(chrome_child.dll -chrome_main.cc:84 )	ChromeMain
0x0088830b	(chrome.exe -main_dll_loader_win.cc:183 )	MainDllLoader::Launch(HINSTANCE__ *)
0x008879a9	(chrome.exe -chrome_exe_main_win.cc:230 )	wWinMain
0x008b6ae9	(chrome.exe -crt0.c:251 )	__tmainCRTStartup
0x762533a9	(kernel32.dll + 0x000133a9 )	BaseThreadInitThunk
0x77b69f71	(ntdll.dll + 0x00039f71 )	__RtlUserThreadStart
0x77b69f44	(ntdll.dll + 0x00039f44 )	_RtlUserThreadStart

As per crash server this crash is not seen in latest canary and dev. seeing 71 instances from different client IDs on current stable/beta
51.0.2704.63	1.67%	71	

Link to the builds:
https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27renderer%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27blink%3A%3AHTMLCanvasElement%3A%3Abuffer%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productversion:1000

ccing few dev whose changes may be related to this crash.

junov@ can you look into this? Looks like canvas is missing some null checks? How do we get there with null?

This is probably a use after free error.  Flagging to Security 

I think this is caused by a bad oilpan pattern.

Because I have no reliable repro, I can only speculate on the cause based on analysis of minidumps.  The minidumps show a state where context has a valid pointer to an HTMLCanvasElement, but the canvas element's reference to the context is a null pointer.  HTMLCanvasElement never resets its m_context pointer, so my hypothesis is that the HTMLCanvasElement was freed and overwritten while the context is still waiting to be GC'ed.

Here is a likely scenario of how we may be ending up in this state:

WebThreadBase::TaskObserver is not a garbage collected type. CanvasRenderingContext2D, which inherits TaskObserver is GarbageCollected.  That on its own is fine because CanvasRenderingContext2D has a prefinalizer that unregisters itself as a task observer prior to destruction. Where things get messy is that the canvas element and the context keep have circular Member references. These inter references are never cleaned-up during tear down, so we can end up in a state where a canvas context pair has no traced references (thus, the pair is available for GC), but there remains an untraced refence to the context as a TaskObserver. Then, there is a chance of getting a partial GC that collects the canvas element, but not the context. Then, if the context gets invoked as a TaskObserver, it may use its reference to the canvas element, which points to deallocated memory. Boom!

I think the solution is for whichever object is destroyed first between the canvas and the context to tear down the circular references.

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

commit a5b85a5aa0b3949351143a35f41f93920db3baea
Author: junov <junov@chromium.org>
Date: Mon Jun 13 22:52:11 2016

Fix canvas-related crash caused by bad object teardown sequence

Made it safe for HTMLCanvasElement and its associated rendering
context to be garbage collected in separate sweeps.

Drive-by: changed ASSERTs to DCHECKs etc.

BUG= 616003 

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

[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/core/html/HTMLCanvasElement.h
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/core/html/canvas/CanvasRenderingContext.cpp
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/core/html/canvas/CanvasRenderingContext.h
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2D.cpp
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2DTest.cpp
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp

The fix landed in comment 6 resolves a possible destruction race that may have been causing the bad state that was at the root of this crash. Since this issue has no clear repro steps we will have to wait and see is the crashes go away before declaring this issue fixed.

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

commit a5b85a5aa0b3949351143a35f41f93920db3baea
Author: junov <junov@chromium.org>
Date: Mon Jun 13 22:52:11 2016

Fix canvas-related crash caused by bad object teardown sequence

Made it safe for HTMLCanvasElement and its associated rendering
context to be garbage collected in separate sweeps.

Drive-by: changed ASSERTs to DCHECKs etc.

BUG= 616003 

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

[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/core/html/HTMLCanvasElement.h
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/core/html/canvas/CanvasRenderingContext.cpp
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/core/html/canvas/CanvasRenderingContext.h
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2D.cpp
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2DTest.cpp
[modify] https://crrev.com/a5b85a5aa0b3949351143a35f41f93920db3baea/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot