1715524 - ThreadSanitizer: data race /builds/worker/checkouts/gecko/gfx/2d/FilterNodeSoftware.cpp:1776:10 in mozilla::gfx::FilterNodeComponentTransferSoftware::GenerateLookupTable(long, unsigned char (*) [256], bool)

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Andrew Osmond [:aosmond] (he/him)]

The following is not thread safe, and when we rasterize blob recordings on WR worker threads, we can conflict:

https://searchfox.org/mozilla-central/rev/79d73b4aff88dd4a0f06dd3789e1148c49b0de60/gfx/2d/FilterNodeSoftware.cpp#1774

This trips tsan failures although since all the threads are writing the same thing, it should be reasonably safe. We need to fix this to green the tree.

Comment 1

[Andrew Osmond [:aosmond] (he/him)]

Do you have any opinions on how this should be fixed? Mutex? (jrmuizel suggested you)

Comment 2

[Markus Stange [:mstange]]

Mutex sounds good, yes. Or maybe it should just be written out in its entirety, it's only 256 values. Then it can be put into static storage and doesn't need to be initialized manually.
This is some silly code, really.

Comment 3

[Andrew Osmond [:aosmond] (he/him)]

Oh good point. We already reserved the static store memory. I'll prep the table in advance. Thanks!

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1715524 - Make FilterNodeComponentTransferSoftware::GenerateLookupTable identify table dynamic.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a9e81cc4ad25
Make FilterNodeComponentTransferSoftware::GenerateLookupTable identify table dynamic. r=jrmuizel

Comment 6

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/a9e81cc4ad25