Bug 286333 – REGRESSION (288648@main): [ x86_64 Release ] fast/dom/set-attribute-and-normalize-in-event.html is constantly failing.

• Component: DOM
• Status: RESOLVED FIXED

[Yasmin Karimi]

fast/dom/set-attribute-and-normalize-in-event.html

This test is constantly failing on macOS x86_64 release.

HISTORY:

https://results.webkit.org/?suite=layout-tests&test=fast%2Fdom%2Fset-attribute-and-normalize-in-event.html

TEXT DIFF: 

@@ -1,3 +1,2 @@
-CONSOLE MESSAGE: RangeError: Maximum call stack size exceeded.
 CONSOLE MESSAGE: RangeError: Maximum call stack size exceeded.

DIFF URL:

https://build.webkit.org/results/Apple-Sequoia-Release-WK2-Tests/289179@main%20(1345)/fast/dom/set-attribute-and-normalize-in-event-pretty-diff.html

REGRESSION:

Contextual information indicates the probable regression point is 288647@main. The code paths changed in that commit appear to be directly related to the observed regression test failure.

[Radar WebKit Bug Importer]

<rdar://problem/143357396>

[EWS]

Test gardening commit 289215@main (36164de5d8b4): <https://commits.webkit.org/289215@main>

Reviewed commits have been landed. Closing PR #39358 and removing active labels.

[Jonathan Bedard]

This seems like it’s probably just a rebaseline, can Anne confirm?

[Anne van Kesteren]

Pull request: https://github.com/WebKit/WebKit/pull/39490

[Anne van Kesteren]

Based on my test PR this regressed due to https://commits.webkit.org/288648@main, not 288647@main. Still trying to determine the best next steps.

[Jonathan Bedard]

This test was added in https://commits.webkit.org/278837@main, I'm quite skeptical that the console messages are actually testing something here.

[Claudio Saavedra]

I was involved in this one and as far as I remember, the log message is irrelevant so it can just be rebaselined.

[Mark Lam]

The reason for the "failure" has nothing to do with x86_64.  Instead, it's simply a function of the machine stack size you're testing on, the relevant frame sizes produced by the compiler, and any number of variables that result in stack usage being slightly different.  Hence, the failure is simply due to the test not being robust against such variations.

Anyway, since the goal of the test isn't to log anything to the console, nor to check how many times a StackOverflow occurs, the way to make this test more robust is to suppress the console log outputs.

[EWS]

merge-queue failed to commit PR to repository. To retry, remove any blocking labels and re-apply merge-queue label

[EWS]

Committed 289441@main (4a21f9329ef5): <https://commits.webkit.org/289441@main>

Reviewed commits have been landed. Closing PR #39490 and removing active labels.