[Webkit-unassigned] [Bug 274802] REGRESSION(274853 at main): [GLib][MSE] Excessive CPU usage from cached web process after closing ksdk.com page, failure to display web content after reopening page, part 2

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=274802

--- Comment #13 from Michael Catanzaro <mcatanzaro at redhat.com> ---
I'm not sure we made the right choice here. The longer we wait to revert, the harder it's going to eventually be. Jean-Yves, your opinion would be helpful.

Anyway, looks like there is a reference leak in a loop somewhere. I added a debug patch:

diff --git a/Source/WebCore/html/HTMLMediaElement.h b/Source/WebCore/html/HTMLMediaElement.h
index 0a87c1f42471..fa15c9453359 100644
--- a/Source/WebCore/html/HTMLMediaElement.h
+++ b/Source/WebCore/html/HTMLMediaElement.h
@@ -174,8 +174,8 @@ public:
     using CanMakeWeakPtr<HTMLMediaElement, WeakPtrFactoryInitialization::Eager>::WeakPtrImplType;

     // ActiveDOMObject.
-    void ref() const final { HTMLElement::ref(); }
-    void deref() const final { HTMLElement::deref(); }
+    void ref() const final { WTFLogAlways("before ref: this=%p refcount=%u", this, refCount()); HTMLElement::ref(); }
+    void deref() const final { WTFLogAlways("before deref: this=%p refcount=%u", this, refCount()); HTMLElement::deref(); }

     MediaPlayer* player() const { return m_player.get(); }
     RefPtr<MediaPlayer> protectedPlayer() const { return m_player; }

There are a bunch of HTMLMediaElements on this page, but only one of them suffers from a continually increasing refcount. For example:

before deref: this=0x7f36d6084660 refcount=41
before deref: this=0x7f36d6084660 refcount=40
before ref: this=0x7f36d60880b0 refcount=2
before ref: this=0x7f36d60880b0 refcount=3
before deref: this=0x7f36d60880b0 refcount=4
before deref: this=0x7f36d60880b0 refcount=3
before ref: this=0x7f36d6087400 refcount=1
before ref: this=0x7f36d6087400 refcount=2
before deref: this=0x7f36d6087400 refcount=3
before deref: this=0x7f36d6087400 refcount=2

When the page is open, every so often the refcount suddenly drops down to a normal level (less than 10 refs). But after closing the page, the refcount remains permanently stuck at the elevated level. Excessive CPU usage begin immediately when the page is closed and never sooner.

I also added breakpoints to the ref and deref functions, but there are a huge number of refs and derefs so I don't think that's a viable path for investigation.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240606/a37cf021/attachment.htm>