Bug 426891

Summary:	Chrome on native Wayland causes a memory leak and excess CPU use in kwin_wayland
Product:	[Plasma] kwin	Reporter:	Greg Varsanyi <gvarsanyi>
Component:	wayland-generic	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	crash
Priority:	NOR
Version First Reported In:	git master
Target Milestone:	---
Platform:	Neon
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Greg Varsanyi 2020-09-23 05:25:37 UTC

SUMMARY

Latest dev versions of Chrome (currently at "87.0.4270.0 dev") finally support native Wayland via Ozone, but kwin_wayland seems to act out around it.

STEPS TO REPRODUCE
1. Get Chrome dev package: https://www.google.com/chrome/dev/?platform=linux&extra=devchannel
2. Run with Ozone/Wayland: google-chrome-unstable --enable-features=UseOzonePlatform --ozone-platform=wayland --disable-gpu

OBSERVED RESULT
kwin_wayland using 100% CPU, and building up memory usage

EXPECTED RESULT
normal CPU use, no memory leak

SOFTWARE/OS VERSIONS
Linux: 5.9rc3
KDE Plasma Version: Neon unstable packages (git master @ Sept 22, 2020, 5.19.90+) 
KDE Frameworks Version: 5.75
Qt Version: 5.15

ADDITIONAL INFORMATION
Does not happen when run via X11 / XWayland, including --ozone=x11
Does not happen when running Firefox native Wayland version.

Comment 1 Vlad Zahorodnii 2020-09-23 12:11:09 UTC

It seems like google chrome floods kwin with xdg_toplevel_decoration_v1.set_mode requests, which forces kwin to re-create decorations every frame.

Comment 2 Greg Varsanyi 2020-09-23 21:07:42 UTC

(In reply to Vlad Zahorodnii from comment #1)
> It seems like google chrome floods kwin with
> xdg_toplevel_decoration_v1.set_mode requests, which forces kwin to re-create
> decorations every frame.

That sounds wrong, I have opened a bug for it: https://bugs.chromium.org/p/chromium/issues/detail?id=1131662

Not freeing memory after dropped decorations is probably still something that needs to be fixed on the kwin side.
And a safeguard mechanism to handle/throttle request floods like this would be great too.

Comment 3 Greg Varsanyi 2020-09-30 23:18:54 UTC

(In reply to Greg Varsanyi from comment #2)
> Not freeing memory after dropped decorations is probably still something
> that needs to be fixed on the kwin side.
> And a safeguard mechanism to handle/throttle request floods like this would
> be great too.

Looks like I was wrong about that, apparently xdg-decoration spec says:
> [...] clients are responsible for preventing configure loops and
> must make sure not to send multiple successive set_mode requests
> with the same decoration mode.

On the Chrome side they have fixed the excessive calls (should be in next release), this ticket can be closed, resolved as "not a bug" on the KDE side.

Comment 4 Vlad Zahorodnii 2020-10-01 06:24:23 UTC

Awesome, thank you for keeping us updated. :-)