Assigning to the concern owner from Predator results --
Git blame below is NOT necessarily who introduced the crash nor the owner for it. Please check the code before assigning to anyone.(No CL in the regression range changed the crashing files.) 

Author: enne
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/e49d70a44bf12043cc781390f7fc53ce7b4ac807
Time: Fri Apr 14 22:27:38 2017
The CL last changed line 16 of file paint_recorder.cc, which is stack frame 1.

@enne -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

msrchandra: I looked into this, but can't understand why this code would be leaking any more than the previous code.  Is there a leak in SkPictureRecorder::beginRecording?  I can't figure out how to search clusterfuzz.

This is a call in PaintLayerCompositor:

  context.Canvas()->PlaybackPaintRecord(builder.EndRecording());

Which makes a DrawRecordOp which has a PaintRecord in it which could be lost due to alignment problems in 712038

I see plenty of leaks happening when i open/close the print dialog and scroll around. They are different stacks for me, as these repro gestures are a little.. intense.


This one is most similar:
Direct leak of 280 byte(s) in 1 object(s) allocated from:
    #0 0x555d12e60362 in operator new(unsigned long) (/usr/local/google/home/danakj/s/c/src/out_desktop/Release/chrome+0x30b7362)
    #1 0x555d268ea509 in cc::PaintRecorder::beginRecording(SkRect const&) cc/paint/paint_recorder.cc:16:17
    #2 0x555d21380ed0 in blink::GraphicsContext::BeginRecording(blink::FloatRect const&) third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp:271:29
    #3 0x555d213ac1ce in blink::DrawingRecorder::DrawingRecorder(blink::GraphicsContext&, blink::DisplayItemClient const&, blink::DisplayItem::Type, blink::FloatRect const&) third_party/WebKit/Source/platform/graphics/paint/DrawingRecorder.cpp:55:11
    #4 0x555d289fe2b3 in blink::ScrollbarTheme::PaintScrollCorner(blink::GraphicsContext&, blink::DisplayItemClient const&, blink::IntRect const&) third_party/WebKit/Source/platform/scroll/ScrollbarTheme.cpp:213:19


And this is 2nd closest, both on exit:

Indirect leak of 160 byte(s) in 1 object(s) allocated from:
    #0 0x555d12e34ba5 in __interceptor_realloc (/usr/local/google/home/danakj/s/c/src/out_desktop/Release/chrome+0x308bba5)
    #1 0x555d1a803863 in sk_realloc_throw(void*, unsigned long) skia/ext/SkMemory_new_handler.cpp:43:35
    #2 0x555d1b689189 in realloc third_party/skia/include/core/../private/SkTemplates.h:265:41
    #3 0x555d1b689189 in cc::PaintOpBuffer::ShrinkToFit() cc/paint/paint_op_buffer.cc:552
    #4 0x555d268ea768 in cc::PaintRecorder::finishRecordingAsPicture() cc/paint/paint_recorder.cc:35:12
    #5 0x555d21381206 in blink::GraphicsContext::EndRecording() third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp:295:47
    #6 0x555d213ac495 in blink::DrawingRecorder::~DrawingRecorder() third_party/WebKit/Source/platform/graphics/paint/DrawingRecorder.cpp:91:47


When I run it with the patch I don't get these leaks. I do see some in printing code such as 

Indirect leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x55d898b9e362 in operator new(unsigned long) (/usr/local/google/home/danakj/s/c/src/out_desktop/Release/chrome+0x30b7362)
    #1 0x55d8a4626fe9 in MakeUnique<SkMemoryStream, const void *&, unsigned long &, bool> base/memory/ptr_util.h:56:29
    #2 0x55d8a4626fe9 in printing::PdfMetafileSkia::InitFromData(void const*, unsigned long) printing/pdf_metafile_skia.cc:112
    #3 0x55d89ed63820 in printing::PrintViewManagerBase::OnDidPrintPage(PrintHostMsg_DidPrintPage_Params const&) chrome/browser/printing/print_view_manager_base.cc:175:20
    #4 0x55d89ed655b3 in DispatchToMethodImpl<printing::PrintViewManagerBase *, void (printing::PrintViewManagerBase::*)(const PrintHostMsg_DidPrintPage_Params &), const std::__1::tuple<PrintHostMsg_DidPrintPage_Params> &, 0> base/tuple.h:77:3
    #5 0x55d89ed655b3 in DispatchToMethod<printing::PrintViewManagerBase *, void (printing::PrintViewManagerBase::*)(const PrintHostMsg_DidPrintPage_Params &), const std::__1::tuple<PrintHostMsg_DidPrintPage_Params> &> base/tuple.h:84
    #6 0x55d89ed655b3 in DispatchToMethod<printing::PrintViewManagerBase, void (printing::PrintViewManagerBase::*)(const PrintHostMsg_DidPrintPage_Params &), void, std::__1::tuple<PrintHostMsg_DidPrintPage_Params> > ipc/ipc_message_templates.h:26
    #7 0x55d89ed655b3 in bool IPC::MessageT<PrintHostMsg_DidPrintPage_Meta, std::__1::tuple<PrintHostMsg_DidPrintPage_Params>, void>::Dispatch<printing::PrintViewManagerBase, printing::PrintViewManagerBase, void, void (printing::PrintViewManagerBase::*)(PrintHostMsg_DidPrintPage_Params const&)>(IPC::Message const*, printing::PrintViewManagerBase*, printing::PrintViewManagerBase*, void*, void (printing::PrintViewManagerBase::*)(PrintHostMsg_DidPrintPage_Params const&)) ipc/ipc_message_templates.h:121
    #8 0x55d89ed64fb1 in printing::PrintViewManagerBase::OnMessageReceived(IPC::Message const&, content::RenderFrameHost*) chrome/browser/printing/print_view_manager_base.cc:278:5
    #9 0x55d89ed14c70 in printing::PrintViewManager::OnMessageReceived(IPC::Message const&, content::RenderFrameHost*) chrome/browser/printing/print_view_manager.cc:249:32

I also see these printing leaks on TOT so that's not related, looks like alignedmemory will fix this bug too.