Task redo has been performed for a regression range.
Thank You.

Predator and CL could not provide any possible suspects.
Using Code Search for the file, "Renderer.cpp" & "Device.cpp" assigning to the concern owner who might be related or worked on similar file.

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


Thank You.

updateConfiguration() sets some Renderer variables and creates events and worker threads, so I assume the worker threads could be reading Renderer variables which still have their old value. I'd expect the thread creation itself to have a full memory fence though.

Probably another false positive (at least on x86), and clusterfuzz says it's not reproducible, but we'll have a look in due time.

ClusterFuzz has detected this issue as fixed in range 500160:500190.

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

Fuzzer: ochang_domfuzzer
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race WRITE 4
Crash Address: 0x7fd0a7bf6050
Crash State:
  sw::Renderer::updateConfiguration
  sw::Renderer::Renderer
  es2::Device::Device
  
Sanitizer: thread (TSAN)

Fixed: https://clusterfuzz.com/revisions?job=linux_tsan_chrome_mp&range=500160:500190

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

See https://github.com/google/clusterfuzz-tools 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 6056866475147264 is verified as fixed, so closing issue as verified.

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

 Issue 767865  has been merged into this issue.