Bug 375971 - kwin_wayland take 100% CPU
Summary: kwin_wayland take 100% CPU
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-03 20:14 UTC by Mustafa Muhammad
Modified: 2018-08-09 07:09 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
strace -t (141.55 KB, text/plain)
2017-02-03 20:14 UTC, Mustafa Muhammad
Details
strace (136.87 KB, text/plain)
2017-02-03 20:14 UTC, Mustafa Muhammad
Details
strace -c (1.03 KB, text/plain)
2017-02-03 20:15 UTC, Mustafa Muhammad
Details
kwin_wayland trace (21.80 KB, text/plain)
2017-02-08 17:08 UTC, Mustafa Muhammad
Details
trace with debug packages installed (29.34 KB, text/plain)
2017-02-09 04:32 UTC, Mustafa Muhammad
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mustafa Muhammad 2017-02-03 20:14:11 UTC
Created attachment 103804 [details]
strace -t

Using Neon Wayland Dev Unstable (git master), kwin_wayland is taking 100 of CPU core, and memory usage wet up to 2G then down again, but CPU stayed 100% (about an hour now), I asked in #kwin and they suggested using strace, so this is some output, something wrong with sendmsg and recvmsg.
Comment 1 Mustafa Muhammad 2017-02-03 20:14:43 UTC
Created attachment 103805 [details]
strace
Comment 2 Mustafa Muhammad 2017-02-03 20:15:07 UTC
Created attachment 103806 [details]
strace -c
Comment 3 Martin Flöser 2017-02-04 07:28:22 UTC
What might be better is a gdb backtrace of the stuck process.

In general it works in neon wayland dev unstable, I'm just writing in such a session.
Comment 4 Mustafa Muhammad 2017-02-08 17:08:00 UTC
It happens sometimes, I didn't use gdb before, I used:
gdb -p `pidof kwin_wayland` -ex bt -ex 'thread apply all bt full' -ex detach -ex quit &> kwin_wayland_trace

to create the attached file, hope it helps, please let me know if there is anything else I can provide
Comment 5 Mustafa Muhammad 2017-02-08 17:08:48 UTC
Created attachment 103904 [details]
kwin_wayland trace
Comment 6 Martin Flöser 2017-02-08 17:55:08 UTC
Difficult to say. We have many "No symbol table info available." which means we don't see the actual code line. What we see is it is dispatching the Wayland server event loop.
Comment 7 Mustafa Muhammad 2017-02-09 04:32:49 UTC
Created attachment 103912 [details]
trace with debug packages installed

I installed all debug packages I could find in the file and generated a new trace.
Comment 8 Martin Flöser 2017-02-09 16:39:23 UTC
It hit a completely different place. This time we don't have Wayland server event loop in the backtrace.
Comment 9 Mustafa Muhammad 2017-02-09 17:18:19 UTC
It is the same process, still running until now if you want something, maybe different timing can cause different gdb output :)
Comment 10 Martin Flöser 2017-02-09 18:47:59 UTC
> It is the same process, still running until now if you want something,
> maybe
> different timing can cause different gdb output :)

sure, sure. But if we have 100 % cpu usage cases, it's quite often, that 
gdb ends in the same area. Which is why I was interested in gdb in the 
first place. I just hoped, that it ends up always in the same spot - 
that would make investigating easier.
Comment 11 tromzy 2017-03-08 14:13:38 UTC
Getting this too. On Arch Linux, Plasma 5.9.3, Kwin_wayland suddenly took 100% of one core of my CPU after a few hours of use.
Comment 12 Andrei Amuraritei 2017-04-19 19:26:45 UTC
Hi, I'm seeing this also on Fedora 25 x86_64 with Plasma 5.9.4, choosing the wayland sesssion and logging in or starting a nested wayland session shows kwin_wayland using 100% cpu.

This on a optimus Acer laptop (intel 530 skylake and nouveau for nvidia gtx950m).
Comment 13 José Pekkarinen 2017-06-01 13:01:49 UTC
Same here with gentoo, unmasking plasma 5.9.5. Is there any interesting info I could share to ease the debugging? I'm afraid debugging symbols won't be there either.

Thanks!

José.
Comment 14 Martin Flöser 2017-07-22 15:10:06 UTC
What I need is to know where the problem happens. For that I ideally get a backtrace with debug symbols. Without that all is just guessing unfortunately.
Comment 15 Mustafa Muhammad 2017-07-23 07:52:39 UTC
(In reply to Martin Flöser from comment #14)
> What I need is to know where the problem happens. For that I ideally get a
> backtrace with debug symbols. Without that all is just guessing
> unfortunately.

I'll try to provide another backtrace with debug symbols (I think I already provided one), but the session is very unstable these days (crash when I traverse the menu), so maybe later.
Comment 16 Alexander Mentyu 2018-07-13 15:10:13 UTC
Is this issue still reproducible?
Comment 17 Mustafa Muhammad 2018-08-09 06:23:58 UTC
(In reply to Alexander Mentyu from comment #16)
> Is this issue still reproducible?

I don't think so, at least not for me, I don't mind closing it, it's your call.
Comment 18 tromzy 2018-08-09 06:58:05 UTC
It stopped happening here too.
Comment 19 José Pekkarinen 2018-08-09 07:01:37 UTC
I'm already far from the versions this happened to me too, so not reproducing anymore, it can be closed.
Comment 20 Christoph Feck 2018-08-09 07:09:05 UTC
Thanks for the update; closing.