[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Flöser]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #19 from Martin Flöser  ---
The copy but is a different issue and sounds a lot like a bug in Qt. Please
report there.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #18 from mbeller...@ypsilon.net ---
50 days have past on my machine.
$ uptime
 10:54:38 up 50 days, 4 min

Alt-Tab is still working. I can move and resize windows around.
Nice.

But copying from old windows is still broken.
When I copy (mouse select, mouse select - right click - copy, select Ctrl-C) in
KDE/Qt-Windows, nothing is copied. No new entry in klipper. And something
different then the copied thing when I paste somewhere (Ctrl-V, mouse middle
click, mouse right click - paste).
It seems specific to those KDE/Qt-Windows, because copying from Firefox, XTerm,
GVim still works. And pasting in old KDE/Qt-Windows works too.
When I restart the application, it works normally again.

Debian-Testing
$ dpkg -l | grep kwin
ii  kwin-addons  4:5.8.5-2 
   amd64additional desktop and window switchers for
KWin
ii  kwin-common  4:5.8.7-1 
   amd64KDE window manager, common files
ii  kwin-data4:5.8.7-1 
   all  KDE window manager data files
ii  kwin-style-breeze4:5.8.5-2 
   amd64KWin Breeze Style
ii  kwin-x11 4:5.8.7-1 
   amd64KDE window manager, X11 version
ii  libkwin4-effect-builtins14:5.8.7-1 
   amd64KDE window manager effect builtins library
ii  libkwineffects9  4:5.8.7-1 
   amd64KDE window manager effects library
ii  libkwinglutils9  4:5.8.7-1 
   amd64KDE window manager gl utils library
ii  libkwinxrenderutils9 4:5.8.7-1 
   amd64KDE window manager render utils library
ii  qml-module-org-kde-kwindowsystem:amd64   5.28.0-1  
   amd64provides integration of QML and KDE
frameworks - kwindowsystem

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Flöser]

https://bugs.kde.org/show_bug.cgi?id=377901

Martin Flöser  changed:

   What|Removed |Added

 CC||mbeller...@ypsilon.net

--- Comment #17 from Martin Flöser  ---
*** Bug 381823 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=377901

Martin Gräßlin  changed:

   What|Removed |Added

   Version Fixed In||5.8.7
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
  Latest Commit||https://commits.kde.org/kwi
   ||n/0bec9ad7337536e319c17c568
   ||4d97e1156399fdb

--- Comment #16 from Martin Gräßlin  ---
Git commit 0bec9ad7337536e319c17c5684d97e1156399fdb by Martin Gräßlin.
Committed on 03/05/2017 at 19:36.
Pushed by graesslin into branch 'Plasma/5.8'.

Improve the x11 timestamp handling

Summary:
So far KWin only updated the x11 timestamp if the new timestamp is larger
than the existing one. While this is a useful thing it creates problems
when the 32 bit msec based time stamp wraps around which happens after
running an X server for 49 days. After the timestamp wrapped around KWin
would not update the timestamp any more and thus some calls might fail.
Most prominent victims are keyboard and pointer grab which fails as the
timestamp is either larger than the server timestamp or smaller than the
last grab timestamp.

Another problem related to timestamp handling is KWin getting broken by
wrong timestamps sent by applications. A prominent example is clusterssh
which used to send a timestamp as unix time which is larger than the
x timestamp and thus our timestamp gets too large.

This change addresses these problems by allowing to reset the timestamp.
This is only used from updateXTime (which is normally invoked before we
do things like grabKeyboard). Thus we make QX11Info::getTimestamp the
ultimate trusted source for timestamps.
Related: bug 348569
FIXED-IN: 5.8.7

Test Plan: As I cannot wait 50 days: unit tests for the two conditions added.

Reviewers: #kwin, #plasma

Subscribers: plasma-devel, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D5704

M  +11   -0autotests/CMakeLists.txt
A  +123  -0autotests/test_x11_timestamp_update.cpp [License: GPL (v2)]
M  +6-2main.h
M  +1-1utils.cpp
M  +3-3utils.h

https://commits.kde.org/kwin/0bec9ad7337536e319c17c5684d97e1156399fdb

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Kenneth Lakin]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #15 from Kenneth Lakin  ---
(In reply to Christian Gerloff from comment #14)
> The devs help themselves by setting the initial value of
> that counter very high, so a wrap occurs soon after boot:

Why's that better than doing what the X server is documented to do, [0] namely:

"Timestamp values wrap around (after about 49.7 days). The server, given its
current time is represented by timestamp T, always interprets timestamps from
clients by treating half of the timestamp space as being later in time than T."

[0] And almost certainly _does_ do, given that KWin 4 and numerous other X11
window managers manage to run for > 49.7 days without issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=377901

Martin Gräßlin  changed:

   What|Removed |Added

URL||https://phabricator.kde.org
   ||/D5704
  Flags||ReviewRequest+

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Christian Gerloff]

https://bugs.kde.org/show_bug.cgi?id=377901

Christian Gerloff  changed:

   What|Removed |Added

 CC||chrgerl...@gmx.net

--- Comment #14 from Christian Gerloff  ---
(In reply to Martin Gräßlin from comment #13)
> well I would like to fix it for good and not have to wait for the next bug
> fix release + 50 days to figure out whether it worked ;-)

The Linux kernel also has a counter that could wrap around and produce
potential errors. The devs help themselves by setting the initial value of that
counter very high, so a wrap occurs soon after boot:

/*
 * Have the 32 bit jiffies value wrap 5 minutes after boot
 * so jiffies wrap bugs show up earlier.
 */
#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))


Could the same be done for the X-Server, if just for debugging and testing?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #13 from Martin Gräßlin  ---
> I would _expect_ that XCB wouldn't do something that runs contrary to the
> xlib documentation's definition of basic datatypes, such as timestamps.
> Maybe you've gotten bitten by just such an incompatibility, though?

Unfortunately yes. Recent case: https://phabricator.kde.org/D5549

Also there are differences in the library. E.g. Xlib is older than 64 bit, so
some parts which are in the protocol defined as int32 are set to long in Xlib,
which results in nice incompatible code on 64 bit. So yeah it doesn't match 1:1
and in these aspects doesn't match the X protocol. That's why I don't trust the
XLib library any more for interaction with X.

Anyway I checked the x protocol and timestamp is a card32 which would support
the description of XLib. Unfortunately the x protocol doesn't talk about how
timestamps are intended to be.

> 
> > Also a spec is one thing, the other is how the one and only
> > X-Server behaves.
> 
> True, but I expect a few things to be true
> * xlib's description of how timestamp rollover is handled in the X server is
> how it's intended to be handled.
> * The x.org developers working on the parts of the server that handle
> timestamps aren't careless noobs, so xorg's handling of timestamp rollover
> is going to match the described behavior.
> 
> > Long story short: I don't trust any x documentation.
> 
> That's not an entirely unreasonable stance to have. But, if you can't easily
> test to check whether the documented behavior matches the implemented
> behavior, isn't it more pragmatic to code as if the documented behavior is
> true, and rely on user bug reports (supported by "The implemented behavior
> didn't match the docs!" prints in the code, where practical) to let you know
> when the implementation doesn't match the docs? :)

well I would like to fix it for good and not have to wait for the next bug fix
release + 50 days to figure out whether it worked ;-)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Kenneth Lakin]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #12 from Kenneth Lakin  ---
(In reply to Martin Gräßlin from comment #11)
> That is the documentation of Xlib, but KWin uses xcb. Mostly the two
> libraries match, but sometimes there are differences.

Fair enough, but the XCB guide [0] says:

"For XCB, the documentation relies even more heavily on the protocol
specifications. The generated API is an exact mapping to the X protocol; it
translates the C call data into X protocol encoded packets as straightforwardly
as possible."

I would _expect_ that XCB wouldn't do something that runs contrary to the xlib
documentation's definition of basic datatypes, such as timestamps. Maybe you've
gotten bitten by just such an incompatibility, though?

> Also a spec is one thing, the other is how the one and only
> X-Server behaves.

True, but I expect a few things to be true
* xlib's description of how timestamp rollover is handled in the X server is
how it's intended to be handled.
* The x.org developers working on the parts of the server that handle
timestamps aren't careless noobs, so xorg's handling of timestamp rollover is
going to match the described behavior.

> Long story short: I don't trust any x documentation.

That's not an entirely unreasonable stance to have. But, if you can't easily
test to check whether the documented behavior matches the implemented behavior,
isn't it more pragmatic to code as if the documented behavior is true, and rely
on user bug reports (supported by "The implemented behavior didn't match the
docs!" prints in the code, where practical) to let you know when the
implementation doesn't match the docs? :)

[0] https://www.x.org/wiki/guide/xlib-and-xcb/#index5h2

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #11 from Martin Gräßlin  ---
That is the documentation of Xlib, but KWin uses xcb. Mostly the two libraries
match, but sometimes there are differences. Also a spec is one thing, the other
is how the one and only X-Server behaves. Long story short: I don't trust any x
documentation.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Kenneth Lakin]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #10 from Kenneth Lakin  ---
(In reply to Martin Gräßlin from comment #9)
> Some additional investigation results: both moving windows and Alt+Tab
> require a keyboard/pointer grab. The xTime() is going into those requests
> and the documentation says:
> 
> "The request fails with status InvalidTime if the specified time is earlier
> than the last-pointer-grab time or later than the current server time.
> Otherwise, the last-pointer-grab time is set to the specified time, with
> CurrentTime replaced by the current server time."

I may be out of my depth (or reading the wrong documentation), but this quote
seems relevant:

"A timestamp is a time value, expressed in milliseconds. It typically is the
time since the last server reset. Timestamp values wrap around (after about
49.7 days). The server, given its current time is represented by timestamp T,
always interprets timestamps from clients by treating half of the timestamp
space as being later in time than T. One timestamp value, named CurrentTime, is
never generated by the server. This value is reserved for use in requests to
represent the current server time."

via:
https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html#Pointer_Grabbing

So it looks like maybe the X11 folks already handle the timestamp rollover
case, and kwin is being too clever?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #9 from Martin Gräßlin  ---
Some additional investigation results: both moving windows and Alt+Tab require
a keyboard/pointer grab. The xTime() is going into those requests and the
documentation says:

"The request fails with status InvalidTime if the specified time is earlier
than the last-pointer-grab time or later than the current server time.
Otherwise, the last-pointer-grab time is set to the specified time, with
CurrentTime replaced by the current server time."

If we don't update the xTime any more due to overflow we are in the situation
that our specified time is "later than current server time". On the other hand
if we pass the new wrapped around number we fall into the condition that
"specified time is earlier than the last-pointer-grab time".

To illustrate: let's assume the last-pointer-grab time is 2^32, Now we
increment by 1 and will have a server time of 0. If we send in 0 it is earlier
than the last-pointer-grab time. On the other hand if we send in our last state
from updating X time we are later than the server time.

To a certain degree this is broken in the X11 specification and if the X-Server
behaves exactly like described in the spec we won't be able to fix it. KWin
cannot use the CurrentTime check as we need to be explicit in the time we
request, or we would run into other bugs. So currently what I see is that we
need to relax our conditions in order to get the grab still working, but window
management will probably still be broken, till some other application requests
a pointer grab with 0.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=377901

Martin Gräßlin  changed:

   What|Removed |Added

   Severity|normal  |critical
   Priority|NOR |HI
  Component|platform-x11-standalone |core

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #8 from Martin Gräßlin  ---
Relevant commit in KWin is:
commit d95ab94f0a664c09223cf1b6d273da41b1cb625e
Author: Martin Gräßlin 
Date:   Thu Feb 19 09:59:21 2015 +0100

Migrate away from QX11Info::appTime

The porting to Qt5 broke the timestamp handling in many areas. A deeper
look into Qt's xcb plugin shows that the appTime handling is not
sufficient for KWin's need. E.g. the time is only updated in response to
a property notify event if it's for a Qt created window, which is hardly
ever the case in KWin. Another example is that key press/release events
never updated the appTime.

As the functionality in Qt is rather trivial we can do the timestamp
handling ourselves. We filter all events anyway and it is slightly faster
as we don't have to go through the QPA interface any more.



This means I need to compare how it was done in Qt 4.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #7 from Martin Gräßlin  ---
We do have the following code:

void setX11Time(xcb_timestamp_t timestamp) {
if (timestamp > m_x11Time) {
m_x11Time = timestamp;
}
}

this means if the timestamp wraps around we will never update again. And the
x11Time is used for various checks. So this is clearly fishy. I need to check
in our git log why we did the sanity checking here, but I'm sure there is a
good reason for it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Kenneth Lakin]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #6 from Kenneth Lakin  ---
> We do have sanity checks there, maybe they need to be weakened.

I'm 100% certain that I had uninterrupted KDE4 sessions that ran trouble-free
for longer than 50 days.

Best of luck in tracking down the errors. Thanks for looking at this!

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #5 from Martin Gräßlin  ---
Waiting for 49 from a dev running the system in a VM won't really help you. All
we could know then is that we can reproduce it, that info is not worth to wait
two days.

The good information is the 32 bit msec timestamp. Those are used a lot on X11
so it's quite likely that they overflow. I try to investigate where they are
used and what a smaller timestamp might mean. We do have sanity checks there,
maybe they need to be weakened.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Christoph Feck]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #4 from Christoph Feck  ---
49 days are 2^32 ms, so it might be because of a timer only using 32 bit.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Kenneth Lakin]

https://bugs.kde.org/show_bug.cgi?id=377901

Kenneth Lakin  changed:

   What|Removed |Added

 CC||kennethla...@gmail.com

--- Comment #3 from Kenneth Lakin  ---
This affects me, too, exactly as described.

I'm using 32-bit ~x86 Gentoo Linux on a 32-bit system.

KWin/Plasma 5.9.2
QT 5.7.1 and 4.8.7
xorg 7.4-r2
Wayland is not installed.

I'm using kwin_x11 rather than kwin_wayland

If I refrain from either Alt+Tabbing _or_ switching virtual desktops, kwin is
perfectly happy to keep resizing and moving windows. If I do _either_ of those
things, kwin emits a single "QXcbConnection: XCB error: 3 ... " message to
stdout every time I try to move or resize a window. Alt+Tab doesn't produce any
messages to stdout.

While kwin is failing to resize/move windows, I can:

Alter window Z-order (either by clicking on a window's titlebar or using the
raise/lower window keyboard shortcuts)
Switch between virtual desktops.
Create new windows.
Close windows.
Start krunner (but unlike normal (where it automatically gets keyboard focus) I
have to manually click it for it to have keyboard focus).

The only "fix" is to restart kwin_x11 and never press alt+tab, or switch
virtual desktops. :(

I've tried restarting kwin_x11 by doing all of

killall kwin_x11 ; sleep $X ; kwin_x11 &
kwin_x11 --replace &
kstart5 -- kwin_x11 --replace 
kwrapper5 kwin_x11 --replace &

None of them fix the problem.

I've gotta use this computer for work, so I'm going to begrudgingly go throw
all my state in a trash fire and restart KDE. I politely suggest that someone
fire up a VM and leave it running for ~49.5 days to debug this. Some of us have
long-running systems that we don't want to have to restart for no reasonable
reason.

(Don't get me wrong. As a programmer, I get that KDE is a complicated system.
I'm also fully aware that most folks working on it are volunteers. :) I'm also
aware that the faulty component might not even be _in_ KDE. But, like, _Windows
95_ was affected by this sort of error. Everyone who _ever_ works with anything
having to do with time should have learned from that. ;))

I'm more than happy to provide additional information upon request. :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Sven-Haegar Koch]

https://bugs.kde.org/show_bug.cgi?id=377901

--- Comment #2 from Sven-Haegar Koch  ---
As the platform of the bug says this is Debian Unstable, which at least right
now still has 5.8.5.

haegar@aurora:~$ kwin_x11 --replace
Module 'org.kde.kwin.decoration' does not contain a module identifier directive
- it cannot be protected from external registrations.
kwin_core: Compositing is not possible
QPainter::begin: Paint device returned engine == 0, type: 3
QPainter::setRenderHint: Painter must be active to set rendering hints
QPainter::setWindow: Painter not active
QPainter::setClipRect: Painter not active
QPainter::begin: Paint device returned engine == 0, type: 3
QPainter::setRenderHint: Painter must be active to set rendering hints
QPainter::setWindow: Painter not active
QPainter::setClipRect: Painter not active

Clicking on a window titlebar to move it gets the output:

QXcbConnection: XCB error: 3 (BadWindow), sequence: 6086, resource id:
44119848, major code: 2 (ChangeWindowAttributes), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 7820, resource id:
67109147, major code: 18 (ChangeProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 9398, resource id:
67109148, major code: 18 (ChangeProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 9614, resource id:
67109149, major code: 18 (ChangeProperty), minor code: 0

Not sure that this bug does not have the same source - but as that bug is
around Cluster-SSH sending invalid timestamps, which I neither use nor have
installed, I decided to open a new one.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 377901] Window movement breaks after 49 days

[Unreal Name]

https://bugs.kde.org/show_bug.cgi?id=377901

Unreal Name <2112...@jeffcoschools.us> changed:

   What|Removed |Added

 CC||2112...@jeffcoschools.us

--- Comment #1 from Unreal Name <2112...@jeffcoschools.us> ---
Sure this is not a duplicate of that bug?
To help diagnose the error, you may need to post the output of either:
kwin-x11 --replace
if you use X11 or
kwin-wayland --replace
if you use Wayland (which is almost perfect in 5.10 previews!)
Plus this is 5.8.5; in neon, also probably in Arch and Parabola, 5.8.6 is
available

-- 
You are receiving this mail because:
You are watching all bug changes.