Predator did not provide any possible suspect.
Assigning to the concern owner from CL --
https://chromium.googlesource.com/chromium/src/+log/7f2791eb558a4bcc8af3313df049fc9a806b6484..62575979076864abba50a3a523f70be61be56f94?pretty=fuller

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/954ca39066bbc77ca7c653c76a02467644c601d2

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

#0 0x7fe637431995 in cc::RasterWithAlphaInternalForFlags(void (*)(cc::PaintOp const*, SkCanvas*, SkMatrix const&), cc::PaintOpWithFlags const*, SkCanvas*, unsigned char) third_party/skia/include/core/SkPaint.h:326:39
#1 0x7fe637431f31 in cc::$_14::__invoke(cc::PaintOp const*, SkCanvas*, unsigned char) cc/paint/paint_op_buffer.cc:100:5
#2 0x7fe6374302ff in cc::PaintOpBuffer::playback(SkCanvas*) const cc/paint/paint_op_buffer.cc:431:3
#3 0x7fe63743148e in cc::PaintOpBuffer::playback(SkCanvas*, SkPicture::AbortCallback*) const cc/paint/paint_op_buffer.cc:613:5
#4 0x7fe63742d46a in cc::(anonymous namespace)::RasterItem(cc::DisplayItem const&, SkCanvas*, SkPicture::AbortCallback*) cc/paint/display_item_list.cc:108:21
#5 0x7fe63742ee05 in cc::DisplayItemList::GenerateDiscardableImagesMetadata() cc/paint/display_item_list.cc:535:5
#6 0x7fe637b49231 in cc::RecordingSource::FinishDisplayItemListUpdate() cc/layers/recording_source.cc:58:18
#7 0x7fe637b498bc in cc::RecordingSource::UpdateDisplayItemList(scoped_refptr<cc::DisplayItemList> const&, unsigned long const&) cc/layers/recording_source.cc:102:3
#8 0x7fe63b20c78f in cc::PictureLayer::Update() cc/layers/picture_layer.cc:129:24
#9 0x7fe637adb37d in cc::LayerTreeHost::DoUpdateLayers(cc::Layer*) cc/trees/layer_tree_host.cc:1066:33
#10 0x7fe637adab38 in cc::LayerTreeHost::UpdateLayers() cc/trees/layer_tree_host.cc:591:17

We're on the main thread, doing raster of a DisplayItemList for GenerateDiscardableImagesMetadata().

Other read was on raster thread:

Read of size 4 at 0x7b2c0001aca4 by thread T7:
#0 0x7fd2b8b560d5 in cc::RasterWithAlphaInternalForFlags(void (*)(cc::PaintOp const*, SkCanvas*, SkMatrix const&), cc::PaintOpWithFlags const*, SkCanvas*, unsigned char) third_party/skia/include/core/SkPaint.h:326:39
#1 0x7fd2b8b56671 in cc::$_14::__invoke(cc::PaintOp const*, SkCanvas*, unsigned char) cc/paint/paint_op_buffer.cc:100:5
#2 0x7fd2b8b54a3f in cc::PaintOpBuffer::playback(SkCanvas*) const cc/paint/paint_op_buffer.cc:431:3
#3 0x7fd2b8b55bce in cc::PaintOpBuffer::playback(SkCanvas*, SkPicture::AbortCallback*) const cc/paint/paint_op_buffer.cc:613:5
#4 0x7fd2b8b51baa in cc::(anonymous namespace)::RasterItem(cc::DisplayItem const&, SkCanvas*, SkPicture::AbortCallback*) cc/paint/display_item_list.cc:108:21
#5 0x7fd2b8b518d3 in cc::DisplayItemList::Raster(SkCanvas*, SkPicture::AbortCallback*) const cc/paint/display_item_list.cc:244:5
#6 0x7fd2b92748b5 in cc::RasterSource::PlaybackToCanvas(SkCanvas*, gfx::ColorSpace const&, cc::RasterSource::PlaybackSettings const&) const cc/raster/raster_source.cc:218:20
#7 0x7fd2b9274512 in cc::RasterSource::PlaybackToCanvas(SkCanvas*, gfx::ColorSpace const&, gfx::Rect const&, gfx::Rect const&, gfx::AxisTransform2d const&, cc::RasterSource::PlaybackSettings const&) const cc/raster/raster_source.cc:84:3
#8 0x7fd2b9273a64 in cc::RasterBufferProvider::PlaybackToMemory(void*, cc::ResourceFormat, gfx::Size const&, unsigned long, cc::RasterSource const*, gfx::Rect const&, gfx::Rect const&, gfx::AxisTransform2d const&, gfx::ColorSpace const&, cc::RasterSource::PlaybackSettings const&) cc/raster/raster_buffer_provider.cc:85:22
#9 0x7fd2b9270a32 in cc::(anonymous namespace)::RasterBufferImpl::Playback(cc::RasterSource const*, gfx::Rect const&, gfx::Rect const&, unsigned long, gfx::AxisTransform2d const&, cc::RasterSource::PlaybackSettings const&) cc/raster/bitmap_raster_buffer_provider.cc:54:5
#10 0x7fd2b92d11d1 in cc::(anonymous namespace)::RasterTaskImpl::RunOnWorkerThread() cc/tiles/tile_manager.cc:130:21
#11 0x7fd2bbf98109 in content::CategorizedWorkerPool::RunTaskInCategoryWithLockAcquired(cc::TaskCategory) content/renderer/categorized_worker_pool.cc:362:28
#12 0x7fd2bbf969db in content::CategorizedWorkerPool::Run(std::__1::vector<cc::TaskCategory, std::__1::allocator<cc::TaskCategory> > const&, base::ConditionVariable*) content/renderer/categorized_worker_pool.cc:341:7


Write was on main thread during GenerateDiscardableImagesMetadata.

Previous write of size 4 at 0x7b2c0001aca4 by main thread:
#0 0x7fd2b864d0c1 in SkPaint::setAlpha(unsigned int) third_party/skia/src/core/SkPaint.cpp:267:12
#1 0x7fd2b8b56100 in cc::RasterWithAlphaInternalForFlags(void (*)(cc::PaintOp const*, SkCanvas*, SkMatrix const&), cc::PaintOpWithFlags const*, SkCanvas*, unsigned char) cc/paint/paint_flags.h:43:49
#2 0x7fd2b8b56671 in cc::$_14::__invoke(cc::PaintOp const*, SkCanvas*, unsigned char) cc/paint/paint_op_buffer.cc:100:5
#3 0x7fd2b8b54a3f in cc::PaintOpBuffer::playback(SkCanvas*) const cc/paint/paint_op_buffer.cc:431:3
#4 0x7fd2b8b55bce in cc::PaintOpBuffer::playback(SkCanvas*, SkPicture::AbortCallback*) const cc/paint/paint_op_buffer.cc:613:5
#5 0x7fd2b8b51baa in cc::(anonymous namespace)::RasterItem(cc::DisplayItem const&, SkCanvas*, SkPicture::AbortCallback*) cc/paint/display_item_list.cc:108:21
#6 0x7fd2b8b53545 in cc::DisplayItemList::GenerateDiscardableImagesMetadata() cc/paint/display_item_list.cc:535:5
#7 0x7fd2b926d9c1 in cc::RecordingSource::FinishDisplayItemListUpdate() cc/layers/recording_source.cc:58:18
#8 0x7fd2b926e04c in cc::RecordingSource::UpdateDisplayItemList(scoped_refptr<cc::DisplayItemList> const&, unsigned long const&) cc/layers/recording_source.cc:102:3
#9 0x7fd2bc93511f in cc::PictureLayer::Update() cc/layers/picture_layer.cc:129:24

This is me changing the SkPaint during raster here: https://cs.chromium.org/chromium/src/cc/paint/paint_op_buffer.cc?q=paint_op_buffer&dr=C&l=84

I was going to pass a PaintFlags to the RasterFunction, which works except for the g_raster_functions, cuz there we have a PaintOp* so it can't tell if there's flags. Resolving that goes back to a template and a lambda like we had before.

I think I could add a RasterWithFlags() method to each PaintOpWithFlags subclass, and have T::Raster() call T::RasterWithFlags, and then Rasterizer::RasterWithAlpha could go to RasterWithFlags directly to override the flags used. That's less symbols I guess than a lambda for every PaintOp.

Does this mean that we'll need to make a copy of the flags for this to work? I guess a shallow copy is ok even if there's a shader or something? Also, is it not acceptable to take a copy of the paintop to make it "mutable"?

No I think we can pass a pointer. It's just sometimes to the op's member and sometimes not.

I guess I mean when the pointer is not to the op's member, what is it a pointer to?

Ah, before this code here https://cs.chromium.org/chromium/src/cc/paint/paint_op_buffer.cc?q=paint_op_buffer&dr=C&l=84 would copy the PaintFlags and modify it, yeah. I'm restoring that.

I have something that compiles, and it doesn't regress the size.

TOT MonochromePublic.apk: 79,762,639 bytes
Fixed MonochromePublic.apk: 79,762,639 bytes

@10, ah ok makes sense thanks.

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

commit 92d629556f9aecd90a2af9785d1a5713dd15b0ba
Author: danakj <danakj@chromium.org>
Date: Thu May 04 20:29:37 2017

cc: Fix data race in PaintOpBuffer by not mutating PaintOps.

Raster can be done on multiple threads at once, so it is not okay to
mutate a PaintOp while doing raster. This fixes the case of
RasterWithAlpha needing to change the PaintFlags back to having it make
a copy. To do this, we add a RasterWithFlags() static method to each
subclass of PaintOpWithFlags, and call that directly with the modified
flags when needed. These subclasses still need to provide a Raster()
method which just passes the |flags| member thru to the
RasterWithFlags().

Before MonochromePublic.apk: 79,762,639 bytes
After MonochromePublic.apk: 79,762,639 bytes

R=enne@chromium.org
BUG= 718309 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/92d629556f9aecd90a2af9785d1a5713dd15b0ba/cc/paint/paint_op_buffer.cc
[modify] https://crrev.com/92d629556f9aecd90a2af9785d1a5713dd15b0ba/cc/paint/paint_op_buffer.h

ClusterFuzz has detected this issue as fixed in range 469439:469538.

Detailed report: https://clusterfuzz.com/testcase?key=5230822151159808

Fuzzer: attekett_dom_fuzzer
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race READ 4
Crash Address: 0x7b2c0001ad54
Crash State:
  cc::RasterWithAlphaInternalForFlags
  cc::$_14::__invoke
  cc::PaintOpBuffer::playback
  
Sanitizer: thread (TSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=469102:469168
Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=469439:469538

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5230822151159808


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5230822151159808 is verified as fixed, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.