Created attachment 96727 [details]
output of strace kwin_x11 --replace (at time of the problem and afterwards)
I have just switched to Plasma 5 (using Arch Linux packages) and SDDM (from previously running KDE4). A severe problem for me is the following: a few times a day KWin stops working properly with errors "Function not implemented" visible in the strace output (see Screenshots). The effective problem for me as the user is that in such a situation (a) copy&paste of both text and files is broken, (b) moving windows by holding left-click on the window titles does not work anymore and (c) the menus in Firefox cannot be clicked on/nor opened with the keyboard combinations anymore.
I cannot reproduce the problem by a particular action but observe it very often (too often in my production environment). I am using Arch Linux with relevant packages kwin 5.5.3-1 and nvidia 358.16-3, i.e., the proprietary NVIDIA driver for my GF119 GPU, also known as GeForce GT 610.
The issue can be basically repaired by restarting kwin with the command kwin_x11 --replace. However, even afterwards (i) copy/paste seems to be broken at least from windows which existed before the kwin restart and (ii) the menus in Firefox cannot be opened and only restarting Firefox completely resolves the latter (which is not very comfortable when using multiple windows with lots of tabs etc.).
bug #353428 ?
If you had actual ENOSYS for the listed functions, your entire installation would be completely fubar, but this is likely due to a segfault.
Do not run kwin (or anything) in strace on a regular base, though.
If this is bug #353428, we'd need to resolve the actual crash, what means to figure what crashes at all - ie. get a backtrace, either via drkonqi or by attaching gdb to the stopped process.
> copy/paste seems to be broken
kwin has no deal in this. Do you happen to use clusterssh?
I do not think this is bug #353428. I have no drkonqi process open at all and kwin seems not to crash completely (e.g. I can still maximize/tile windows/move them to other virtual desktops using my hotkeys; or is this not kwin's reponsibility?).
How can I provide more information? Do I understand you correctly that you think there is a segfault in some (non-kwin) process which propagates to kwin such that kwin itself gets confused and shows these "Function not implemented" signatures in the strace output? If you had more ideas what I could to I would be glad to follow those suggestions.
Actually I am using clusterssh (arch package 4.04-1) but I observed the problem also without having open that program.
Clusterssh screws server tiemstamps which breaks not only input grabbing in KWin but also drag & drop in all Qt5, see bug #348569 resp. https://github.com/duncs/clusterssh/issues/46
All issues you describe match that scenario (except for firefox, where I frankly do not know whether it runs into the same problem, but KWin has no deal in FF or any popupmenus either and popups usually want to grab input...)
=> Check that this condition does *really* not occur after restarting kwin and before starting clusterssh.
The strace condition may be weakly related false positive - the "not implemented" functions are very low level functions of glibc and the kernel.
Just some more info, i had the same behaviour with both firefox and thunderbird (XUL in common?) when using clusterssh. The menus wouldnt open.
In case you've another client that uses server timestamps of the 30ies century, please record them, but from the KWin side, this is the same problem (and likely is just clusterssh)
*** This bug has been marked as a duplicate of bug 348569 ***
I didn't said that it has to do with kwin, i wanted to be helpful adding some more info in case it's needed
Your post *is* helpful.
I didn't mean to directly reply to your message but took it as confirmation that all of the issues in the report are caused by irregular server timestamps - and likely be caused by clusterssh.
Thus marking it as a dupe (which it is, even iff there's a client beyond clusterssh causing this - from the KWin side it really doesn't matter who screws event times, fact is that we - and all of Qt5 - aren't sufficiently robust against that. The WM should ideally not be knocked out by some broken client)
Just to give you an update on this: it might be indeed true that clusterssh was responsible for the behaviour I have reported. At least the problem has not appeared again after closing clusterssh and restarting kwin _afterwards_.
However, from my (user) perspective an application should not be able to induce a core component such as kwin to fail -- even (or especially?) when using very old code ;-)