Bug 217761 - REGRESSION: ASSERTION FAILED: !needsLayout() on webgl/2.0.0/conformance/extensions/webgl-compressed-texture-s3tc-srgb.html (flaky)
Summary: REGRESSION: ASSERTION FAILED: !needsLayout() on webgl/2.0.0/conformance/exten...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-10-15 09:53 PDT by Karl Rackler
Modified: 2020-10-17 18:02 PDT (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Rackler 2020-10-15 09:53:04 PDT
Description:
webgl/2.0.0/conformance/extensions/webgl-compressed-texture-s3tc-srgb.html

The first crash that I see this on the dashboard was 08/31/20 at r266366 and continued to flaky crash until 09/04/20 at r266624 where it began passing consistently.  Then at 09/07/20 at r266714 the flaky crash began again and ended 09/09/20 at r266799.  There is another period of consistent passing from 09/09/20 until 10/06/20 at r268052 where the flaky crash begins again until present.

I can reproduce this on r267662, but unable to reproduce on 267661. Commit r267662 has to do with updating the names everywhere and URLs in IDLAttributes.json, which could have introduced the flaky crash.  The change was introduced here https://trac.webkit.org/changeset/266662/webkit.


REPRODUCTION STEPS
Command: 
run-webkit-tests --exit-after-n-failures 1 --exit-after-n-crashes-or-timeouts 1 --iterations 50 --no-retry --force --no-build -f --debug -1 webgl/2.0.0/conformance/extensions/webgl-compressed-texture-s3tc-srgb.html

Result: 
Regressions: Unexpected crashes (1)
  webgl/2.0.0/conformance/extensions/webgl-compressed-texture-s3tc-srgb.html [ Crash ]

History:
https://results.webkit.org/?suite=layout-tests&test=webgl%2F2.0.0%2Fconformance%2Fextensions%2Fwebgl-compressed-texture-s3tc-srgb.html&platform=mac&style=debug&flavor=wk1&limit=50000

Crash Log:
Application Specific Information:
CRASHING TEST: webgl/2.0.0/conformance/extensions/webgl-compressed-texture-s3tc-srgb.html

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.JavaScriptCore      	0x00000001105ac4fe WTFCrash + 14 (Assertions.cpp:295)
1   com.apple.WebCore             	0x000000012ad8ea6b WTFCrashWithInfo(int, char const*, char const*, int) + 27
2   com.apple.WebCore             	0x000000012eb373f9 WebCore::FrameView::paintContents(WebCore::GraphicsContext&, WebCore::IntRect const&, WebCore::Widget::SecurityOriginPaintPolicy, WebCore::EventRegionContext*) + 697 (FrameView.cpp:4292)
3   com.apple.WebKitLegacy        	0x000000011c5f03e9 -[WebFrame(WebInternal) _drawRect:contentsOnly:] + 1417 (WebFrame.mm:657)
4   com.apple.WebKitLegacy        	0x000000011c614ff6 -[WebHTMLView drawSingleRect:] + 774 (WebHTMLView.mm:3883)
5   com.apple.WebKitLegacy        	0x000000011c615711 -[WebHTMLView drawRect:] + 625 (WebHTMLView.mm:3954)
Comment 1 Radar WebKit Bug Importer 2020-10-15 09:53:46 PDT
<rdar://problem/70340711>
Comment 2 Karl Rackler 2020-10-15 10:04:41 PDT
I have marked this test as flaky crash while this issue is investigated.
https://trac.webkit.org/changeset/268527/webkit
Comment 3 Alexey Proskuryakov 2020-10-15 17:03:40 PDT
r266662 is surprising as a regression point, but if true, that could be a serious problem.
Comment 4 Alexey Proskuryakov 2020-10-17 18:02:06 PDT
This one has a complicated history.

I could reproduce starting with r266364, where WEBGL_compressed_texture_s3tc_srgb extension was implemented. This assertion seems unlikely to have anything to do with S3TC or WebGL, it's probably just because the test started to have a long output after the feature got implemented. It's about 15 pages on my screen.

Then this was completely fixed by r266645, Move lazy DisplayLink tear down logic from the WebProcess to the UIProcess.

It became easily reproducible again after r266710, where the above was reverted.

Then r266645 was re-landed in r266797, but the issue was not completely fixed this time. It's still reproducible, but only about once in a 1000 iterations.

So either the new DisplayLink patch is not as effective as the original one, or something happened between r266710 and r266797 that created a new reason for the test to assert.

This is the only test for a feature, so it's pretty important.