WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
319590
[Skia] Memory growth on every page load when fonts with variations are used
https://bugs.webkit.org/show_bug.cgi?id=319590
Summary
[Skia] Memory growth on every page load when fonts with variations are used
Jeff Fortin
Reported
2026-07-16 08:22:52 PDT
Created
attachment 480621
[details]
heaptrack capture # Symptoms I have
https://app.invoicing.co
(a.k.a.
https://react.invoicing.co/demo
) set up as an Epiphany web app running on Fedora 44's WebKitGTK 2.52.5, and after a few hours of simply using the tasks timer feature, I inevitably end up with a WebKitWebProcess that eats 1.5 to 1.6 GB. On initial start on that tasks page, the process uses about 400 MB. Then if I reload the page, it instantly goes to 570 MB. Another reloads bumps it to 650+ MB. Then 720 MB. Then 808, 862, 911 MB, and so on. It might sometimes shrink a little bit (ex: 10%) while the OS is under memory pressure, but not significantly. In any case, after some hours of use, I always end up in the ~1.5 GB territory for that single page in a single WebKitWebProcess. It happens whether or not ad blockers are activated. # Steps to reproduce Run: /usr/libexec/webkitgtk-6.0/MiniBrowser --private
https://react.invoicing.co/demo
Then navigate to "Tasks", then reload a couple of times, while looking at the process' RAM usage in gnome-system-monitor. In comparison, Chromium manages to keep it at 160-200 MB even if you reload dozens of times, and Firefox also manages to shrink it to ~240 MB. # ProfilinG/measurements From
https://blogs.igalia.com/plampe/wpe-memory-leak-investigation-playbook/
: Doing a `stress --vm 1 --vm-bytes 13100M --vm-keep` to memory pressure it by filling my system RAM at 90%+, I see that the webkitwebprocess's RAM usage shrinks by barely 10%, i.e. it might go back to 950 MB from 1.1 GB. Then I ran this: WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 Malloc=1 /usr/libexec/webkitgtk-6.0/MiniBrowser --private
https://react.invoicing.co/demo
…combined with: heaptrack -p theProcessIDofWebKitWebProcess …and we have the resulting .zst heaptrack file, which says, "peak RSS: 1.2 GB, total memory leaked: 427 MB" I'm attaching the heaptrack .zst capture file and screenshots.
Attachments
heaptrack capture
(48.06 MB, application/zstd)
2026-07-16 08:22 PDT
,
Jeff Fortin
no flags
Details
heaptrack 2026-07-16 screenshot 1 - summary
(228.97 KB, image/png)
2026-07-16 08:41 PDT
,
Jeff Fortin
no flags
Details
heaptrack 2026-07-16 screenshot 2 - bottom-up
(1007.15 KB, image/png)
2026-07-16 08:41 PDT
,
Jeff Fortin
no flags
Details
heaptrack 2026-07-16 screenshot 3 - caller-callee
(963.62 KB, image/png)
2026-07-16 08:41 PDT
,
Jeff Fortin
no flags
Details
heaptrack 2026-07-16 screenshot 4 - top-down
(1.08 MB, image/png)
2026-07-16 08:41 PDT
,
Jeff Fortin
no flags
Details
heaptrack 2026-07-16 screenshot 5 - flame graph
(684.43 KB, image/png)
2026-07-16 08:42 PDT
,
Jeff Fortin
no flags
Details
heaptrack 2026-07-16 screenshot 6 - consumed over time
(323.71 KB, image/png)
2026-07-16 08:42 PDT
,
Jeff Fortin
no flags
Details
heaptrack 2026-07-16 screenshot 7 - allocations over time
(231.62 KB, image/png)
2026-07-16 08:42 PDT
,
Jeff Fortin
no flags
Details
heaptrack 2026-07-16 screenshot 8 - temporary allocations over time
(224.89 KB, image/png)
2026-07-16 08:43 PDT
,
Jeff Fortin
no flags
Details
heaptrack 2026-07-16 screenshot 9 - sizes
(102.72 KB, image/png)
2026-07-16 08:43 PDT
,
Jeff Fortin
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Jeff Fortin
Comment 1
2026-07-16 08:40:10 PDT
It doesn't even have to be the InvoiceNinja app's React interface… The issue also happens simply by reloading the
https://npr.org
front page repeatedly.
Jeff Fortin
Comment 2
2026-07-16 08:41:00 PDT
Created
attachment 480622
[details]
heaptrack 2026-07-16 screenshot 1 - summary
Jeff Fortin
Comment 3
2026-07-16 08:41:17 PDT
Created
attachment 480623
[details]
heaptrack 2026-07-16 screenshot 2 - bottom-up
Jeff Fortin
Comment 4
2026-07-16 08:41:37 PDT
Created
attachment 480624
[details]
heaptrack 2026-07-16 screenshot 3 - caller-callee
Jeff Fortin
Comment 5
2026-07-16 08:41:51 PDT
Created
attachment 480625
[details]
heaptrack 2026-07-16 screenshot 4 - top-down
Jeff Fortin
Comment 6
2026-07-16 08:42:07 PDT
Created
attachment 480626
[details]
heaptrack 2026-07-16 screenshot 5 - flame graph
Jeff Fortin
Comment 7
2026-07-16 08:42:27 PDT
Created
attachment 480627
[details]
heaptrack 2026-07-16 screenshot 6 - consumed over time
Jeff Fortin
Comment 8
2026-07-16 08:42:46 PDT
Created
attachment 480628
[details]
heaptrack 2026-07-16 screenshot 7 - allocations over time
Jeff Fortin
Comment 9
2026-07-16 08:43:09 PDT
Created
attachment 480629
[details]
heaptrack 2026-07-16 screenshot 8 - temporary allocations over time
Jeff Fortin
Comment 10
2026-07-16 08:43:20 PDT
Created
attachment 480630
[details]
heaptrack 2026-07-16 screenshot 9 - sizes
Philippe Normand
Comment 11
2026-07-16 10:43:03 PDT
Looks like this might be skia/fonts related.
Jeff Fortin
Comment 12
2026-07-16 11:51:01 PDT
Another way to reproduce this is to load the website, click on a link to navigate to another page, then use the browser's Back/Forward history buttons; upon each page load, memory consumption increases, even if it's just the same two pages from the history being loaded repeatedly in turns.
Pawel Lampe
Comment 13
2026-07-17 05:36:11 PDT
I was able to reproduce in with latest main 93f2cadf3db76824f0735c7138658e0f3ec8c0d4 - will try to profile on my end as well.
Pawel Lampe
Comment 14
2026-07-20 03:17:52 PDT
I've confirmed this is related to fonts i.e. custom fonts with variations. The problem is that skia-integration code keeps calling typeface->makeClone(fontArgs) even for the same variations and this somehow gets retained. I'll work on this.
Pawel Lampe
Comment 15
2026-07-22 05:13:53 PDT
After further investigation I've realized it's not as bad as it seemed initially. The critical memory pressure is releasing that memory, so it's very likely the browser would never go OOM due to above. Anyway, I have some ideas on how we could avoid cloning typefaces too hard to reduce the memory usage and improve performance. I'll experiment with that.
Pawel Lampe
Comment 16
2026-07-22 05:54:15 PDT
Btw. I've created small demo for easier reproduction of above problem:
https://scony.github.io/web-examples/memory/periodic-font-variation-settings-mutation.html
- it's enough to reload few times to get many cache entries and hence cloned typefaces all backed by freetype-level allocations etc.
Pawel Lampe
Comment 17
2026-07-23 05:31:16 PDT
Pull request:
https://github.com/WebKit/WebKit/pull/70026
EWS
Comment 18
2026-08-03 11:25:39 PDT
Committed
318476@main
(6b324fb4b79e): <
https://commits.webkit.org/318476@main
> Reviewed commits have been landed. Closing PR #70026 and removing active labels.
EWS
Comment 19
2026-08-03 16:18:15 PDT
Committed
305877.1025@webkitglib/2.52
(8fc3e4613a57): <
https://commits.webkit.org/305877.1025@webkitglib/2.52
> Reviewed commits have been landed. Closing PR #70797 and removing active labels.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug