As there is no Regression Revision Range and suspect file, Redo Task has been performed for regression range.
Adding CF-NeedsTriage label, could someone please look into the issue.
Thank You.

Could someone from "WebGL" team can take a look? since this is from "webDEViL_webgl" fuzzer?

Thank you!

It looks like this is a crash inside Mesa's software rasterizer:
/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so+0x272e87

We should switch all of these tests over to using SwiftShader as their renderer. It's likely this is a bug in Mesa. If the same test crashed with SwiftShader, we'd be more likely to investigate it.

It sounds like this flaky crash isn't reproducible. Please indicate if it is.

@kbr is right, it's a crash inside of swrast_dri.so, which is not instrumented since it's not part of the build, this is why we don't have a stacktrace.

The crash is marked as non-reproducible because we cannot find a single input that would reliably reproduce it. However, that crash has been happening several times every day for 14 days in a row, and this is why it's been reported as a bug.

We understand that it's hard to fix without a reliable reproducer, but sometimes it's possible to try a speculative fix based on the stacktrace. In this particular case, for example, kbr@ suggested switching to SwiftShader.

Can we dupe into the bug to switch to swiftshader?

I think it would be better to block on that bug. That way CF will be able to verify if the issue if gone and auto-close this issue.

Note that Layout Tests already use SwiftShader on Linux and  issue 726075  is about replacing Mesa with SwiftShader for the purpose of running Layout Tests.

The test being ran here is not a Layout Test, I think.

We do want to replace Mesa with SwiftShader for every test, but that's after all platforms run Layout Tests using SwiftShader (MacOS is still TBD) and that would probably be several different issues to complete this work for all tests.

If the test mentioned here can be switched to SwiftShader on Linux, it should already be doable, unless doing so requires it to also run using SwiftShader on MacOS.

This particular crash happens without any particular test, it's just Chrome built with ASan and proprietary codecs.

There are GN args at the bottom of CF report: https://clusterfuzz.com/v2/testcase-detail/5455616213778432?noredirect=1

I haven't verified this, but the GN args mention "ChromeOS", and SwiftShader is indeed not yet enabled for ChromeOS. The platform id in the bug description above is "linux", so I thought it was non ChromeOS linux.

"ChromeOS" is used for ffmpeg_branding, not for platform definition: https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/master-backup/ffmpeg.gyp#6

I cannot remember why, but I've been told the following a while ago: For Linux ffmpeg_branding should be set to ChromeOS. For other platforms, use ffmpeg_branding=Chrome.

Ok, then IIUC, the gl implementation is chosen here:
https://cs.chromium.org/chromium/src/ui/gl/init/gl_factory.cc?l=81

In this test, the provided arguments list contains "--use-gl=any" and, on Linux, the default OpenGL implementation is set at https://cs.chromium.org/chromium/src/ui/gl/init/gl_factory_x11.cc?l=31 and is kGLImplementationDesktopGL.

So, on this bot, there some issue in the system's Desktop GL implementation. We could simply switch these tests to use "--use-gl=swiftshader" to force use SwiftShader, if that's the desired behavior.

Thanks for the analysis, Alexis!

Marty and Oliver, it looks like we should change "--use-gl" flag in linux_asan_chrome_media job definition. Are there any reasons not to do this?

Discussed with Marty and Oliver over chat. Actually, we have many different jobs using "--use-gl=any" on different platforms. Is there a list of platforms where swiftshared is supported? How can we distinguish which job types we should update (i.e. switch from "--use-gl=any" to "--use-gl=swiftshared").

I've updated that option for linux_asan_chrome_media, the job type that has been used to find this particular crash.

It should be ok to use SwiftShader on any Windows bot and non ChromeOS linux bots that use X11.

Cool, thanks. Changed the flag for all Windows and non ChromeOS Linux bots: https://bugs.chromium.org/p/chromium/issues/detail?id=782186#c6

Shall we close this?

ClusterFuzz testcase 5455616213778432 is flaky and no longer crashes, so closing issue.

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