Bug 225671 – [ BigSur Release wk2 arm64 ] webgl/2.0.0/conformance2/textures/image_bitmap_from_image_data/tex-2d-rgba16f-rgba-float.html (layout-test) is a flaky crash

• Status: NEW
• Component: Tools / Tests

[Robert Jenner]

webgl/2.0.0/conformance2/textures/image_bitmap_from_image_data/tex-2d-rgba16f-rgba-float.html

is a flaky crash that has only occurred once in recent history on BigSur Release wk2 on Apple Silicon Macs only. 

HISTORY:
https://results.webkit.org/?suite=layout-tests&test=webgl%2F2.0.0%2Fconformance2%2Ftextures%2Fimage_bitmap_from_image_data%2Ftex-2d-rgba16f-rgba-float.html


There was not crashlog collected on the results page:

https://build.webkit.org/results/Apple-BigSur-Release-AppleSilicon-WK2-Tests/r277321%20(1399)/webgl/2.0.0/conformance2/textures/image_bitmap_from_image_data/tex-2d-rgba16f-rgba-float-crash-log.txt

[Robert Jenner]

This has only occurred once in the history. It also only occurred on an Apple Silicon Mac, and as such I can't reproduce it because I do not have access to said system type. I will monitor this to see if it continues to be an issue. The first and only crash so far occurred at r277321.

[Radar WebKit Bug Importer]

<rdar://problem/77856504>

[Kenneth Russell]

Is this configuration running ANGLE's Metal or OpenGL backend?

[Ryan Haddad]

(In reply to Kenneth Russell from comment #3)
> Is this configuration running ANGLE's Metal or OpenGL backend?
Should be whatever is on by default, so I assume ANGLE?

[Kyle Piddington]

Given the crash date, I suspect this was on the ANGLE Metal backend instead of the ANGLE GL backend.

[Alexey Proskuryakov]

Jonathan, do you know what this output means? This almost certainly wasn't a real crash (I also verified that there isn't a crash log in ~/Library/Logs/DiagnosticReports on the bot).

07:48:29.898 21802 com.apple.WebKit.WebContent.Development crash, pid = 33213
07:48:29.960 21802 This test marked as a crash because of no data while reading stdout for the server process.
07:48:29.960 21802 This test marked as a crash because of no data while reading stdout for the server process.
07:49:00.021 21802 worker/1 webgl/2.0.0/conformance2/textures/image_bitmap_from_image_data/tex-2d-rgba16f-rgba-float.html crashed, (no stderr)

[Jonathan Bedard]

(In reply to Alexey Proskuryakov from comment #6)
> Jonathan, do you know what this output means? This almost certainly wasn't a
> real crash (I also verified that there isn't a crash log in
> ~/Library/Logs/DiagnosticReports on the bot).
> 
> 07:48:29.898 21802 com.apple.WebKit.WebContent.Development crash, pid = 33213
> 07:48:29.960 21802 This test marked as a crash because of no data while
> reading stdout for the server process.
> 07:48:29.960 21802 This test marked as a crash because of no data while
> reading stdout for the server process.
> 07:49:00.021 21802 worker/1
> webgl/2.0.0/conformance2/textures/image_bitmap_from_image_data/tex-2d-
> rgba16f-rgba-float.html crashed, (no stderr)

Another way to say this is "the process was unresponsive". We've always put this in the crash bucket, but it's not a true crash, it means that run-webkit-tests got absolutely no output from WebKitTestRunner. The exact rationale as to why we added this is before my time, but it's not something we often encounter, usually timeouts give some output before hanging. Looking at the test name, I wonder if an image diff test that times out doesn't produce any output, it seems plausible that an image diff test timing out is not a case we've dealt with frequently enough to correctly categorize

[Alexey Proskuryakov]

Normally, when a process is unresponsive that's detected by WebKitTestRunner like this:

+#PID UNRESPONSIVE - WebKitTestRunnerApp (pid 68365)
+FAIL: Timed out waiting for notifyDone to be called

So to hit the "no output" case, we have to have WebKitTestRunner itself freeze?

[Alexey Proskuryakov]

But then I don't understand why run-webkit-tests calls is a "com.apple.WebKit.WebContent.Development crash". How does it even know the XPC process name?

[Robert Jenner]

After monitoring this for a week, it appears that this has only crashed the one time, and on the one specific queue.

[Jonathan Bedard]

(In reply to Robert Jenner from comment #10)
> After monitoring this for a week, it appears that this has only crashed the
> one time, and on the one specific queue.

A bit unfortunate that we didn't see a reproduction. This seems like another possible case of "WebContent process was asked to terminate because of bad IPC", and logging added late last week would be able to corroborate....