Closed vnd closed 2 months ago
vnd
commented
1 year ago Upon further testing, leak is happening upon loading videos, and not during playback itself. Since we have a bit edgy use case with very short videos (~3 seconds) being played repeatedly, it resulted in a big memory leak. Hopefully UI guys can just switch to a longer videos, then the leak will be negligible.
calvaris
commented
2 months ago Just pushed 0cb500e1545c . It includes several leak fixes that where upstream but the one that is creating the biggest impact is done by 23a801c4061c after empirical testing . There are some cases where process memory size decreases with or without these patches, but what is definitely sure is that with these commits the memory increase is far less steep. Closing then.
septatrix
commented
2 months ago You could also check if the number of open fds increases. There seems to be a leak of those some users (including me) are experiencing: https://bugs.webkit.org/show_bug.cgi?id=260723 / https://bugs.webkit.org/show_bug.cgi?id=277076
I'm trying to play 3 short videos (~2-3 seconds each) in a loop on an i.MX6DL board, running Yocto image (dunfell).
wpewebkit 2.38.3 cog 0.14.1 gstreamer 1.16.3 IMX_DEFAULT_BSP = "mainline" wpebackend-fdo
Simple HTML page is playing 3 videos in a loop: https://gist.github.com/vnd/88449eb6fb6d688bc6f4882f18b2736e
WPEWebProcess RssAnon memory is growing with a speed of about 0.7MiB/minute, and eventually OOM killer kicks in.
The only caveat of the above example is that for some reason every couple of playbacks 'ended' event is not fired, and so I've added a timeout for resuming playback. Not sure if it could be causing the leak, but either way there's a bug somewhere. Note: this page is a minimal reproducible example, production UI leaks 2-3 times faster.
Apart from hopefully fixing the leak, even slowing it down could help. Also I'm genuinely curious in all relevant info, in particular what is leaking: wpewebkit, gstreamer plugins, kernel or cog?