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
Summary: [ BigSur Release wk2 arm64 ] webgl/2.0.0/conformance2/textures/image_bitmap_f...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks: webglflaky
  Show dependency treegraph
 
Reported: 2021-05-11 12:09 PDT by Robert Jenner
Modified: 2022-04-22 00:22 PDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Jenner 2021-05-11 12:09:09 PDT
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
Comment 1 Robert Jenner 2021-05-11 12:33:00 PDT
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.
Comment 2 Radar WebKit Bug Importer 2021-05-11 12:33:22 PDT
<rdar://problem/77856504>
Comment 3 Kenneth Russell 2021-05-11 12:33:53 PDT
Is this configuration running ANGLE's Metal or OpenGL backend?
Comment 4 Ryan Haddad 2021-05-11 14:30:38 PDT
(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?
Comment 5 Kyle Piddington 2021-05-11 14:48:28 PDT
Given the crash date, I suspect this was on the ANGLE Metal backend instead of the ANGLE GL backend.
Comment 6 Alexey Proskuryakov 2021-05-11 16:36:11 PDT
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)
Comment 7 Jonathan Bedard 2021-05-12 08:16:21 PDT
(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
Comment 8 Alexey Proskuryakov 2021-05-12 12:58:33 PDT
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?
Comment 9 Alexey Proskuryakov 2021-05-12 13:02:10 PDT
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?
Comment 10 Robert Jenner 2021-05-19 15:22:28 PDT
After monitoring this for a week, it appears that this has only crashed the one time, and on the one specific queue.
Comment 11 Jonathan Bedard 2021-05-19 16:01:58 PDT
(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....