intersection-observer/target-deleted.html This test is timing out constantly sense around r271473 History: https://results.webkit.org/?suite=layout-tests&test=intersection-observer%2Ftarget-deleted.html I can reproduce this with command: run-webkit-tests --iterations 2000 --exit-after-n-failures 1 --exit-after-n-crashes-or-timeouts 1 --debug-rwt-logging --no-retry --force --no-build -f intersection-observer/target-deleted.html
<rdar://problem/73220571>
I was able to bisect this to r271471
(In reply to Truitt Savell from comment #2) > I was able to bisect this to r271471 r2714712 fails while r271471 passes actually. misstyped
You mean https://trac.webkit.org/changeset/271472/webkit. Seems pretty unlikely that's the cause.
Hmm, I can't reproduce it on Catalina debug wk2. It seems specific to the release versions. I'll try to build release locally.
(In reply to cathiechen from comment #5) > Hmm, I can't reproduce it on Catalina debug wk2. > It seems specific to the release versions. > I'll try to build release locally. Tried the release version on macOS Catalina and Big Sur, but can't reproduce it.
I can reproduce with Truitt's command.
Even a single iteration is sufficient (which is consistent with the bots, and will make debugging easier).
The observerShouldBeRemoved interval is firing forever, with 1 outstanding intersection observer live (i.e., the test is catching exactly the failure it was intended to fix...)
Nothing even remotely near the regression point makes any sense, so I'm just going to see if I can debug.
Test was introduced in https://trac.webkit.org/changeset/237880/webkit
I think this is just a test depending on GC and the GC not happening (despite the attempt to force it). If I run the test with --no-timeout, it spins forever, UNTIL the instant I try to remote-web-inspect it, then suddenly the element is collected, the IntersectionObserver goes away, and the test completes...
Oh, try increasing the number of observers and check if any observer is collected? I suspect the test is buggy. Since we have a conservative GC, we can't guarantee all objects will be collected.
Maybe the test needs to do something non-trivial in the loop to make gc() do something
Wait, also, m_intersectionObservers is a Vector of WeakPtrs, and we're just getting its length... which won't decrease if one of the WeakPtrs gets zeroed, right? This is all a bit questionable.
(In reply to Simon Fraser (smfr) from comment #14) > Maybe the test needs to do something non-trivial in the loop to make gc() do > something It's never guaranteed that gc() will collect all garbage because we have a conservative GC. Some objects can be kept alive even if they're logically dead.
Created attachment 418108 [details] Patch
Committed r271736: <https://trac.webkit.org/changeset/271736> All reviewed patches have been landed. Closing bug and clearing flags on attachment 418108 [details].