[Fluxbox-users] fluxbox permanentely freezes pointer device

[NEURURER.Anton]

Hi

I am running fluxbox on a touchscreen device. It works several weeks without problems but then suddenly the main application is not usable anymore because fluxbox grabs the pointer device and does not release it.

I used this command to find all active grabs:

***@user:/home/vis# DISPLAY=:0 xdotool key "XF86LogGrabInfo" ; tail -f /var/log/Xorg.0.log -n 30

Which gives following output:

[185910.119] (II) Printing all currently active device grabs:
[185910.120] Active grab 0x41400037 (core) on device 'Virtual core pointer' (2):
[185910.120] client pid 2844 fluxbox
[185910.120] at 179094620 (from passive grab) (device frozen, state 6)
[185910.120] core event mask 0x4
[185910.120] passive grab type 4, detail 0x1, activating key 0
[185910.120] owner-events true, kb 0 ptr 0, confine 0, cursor 0x0
[185910.120] (II) End list of active device grabs

Fluxbox performs a permanent active grab on the mouse device. Therefore the application does not get mouse events. The only solution so far is to reboot the touchscreen device.

I use fluxbox version 1.3.2.

Is this a known bug?

Best regards
Anton

[Thomas Lübking]

Post by NEURURER.Anton
Hi
I am running fluxbox on a touchscreen device. It works several weeks without problems but then suddenly the main application is not usable anymore because fluxbox grabs the pointer device and does not release it.

I've seen this (twice, I think) but thought it would be due to
https://github.com/luebking/fluxbox/commit/fa670bf5a352165baac4f89f83b894a63d5f61cd
(lucky me, then - not my bug ;-)

You do not spot a pattern to reproduce this, did you?

Cheers,
Thomas

------------------------------------------------------------------------------

[NEURURER.Anton]

Hi Thomas

I do not use any version of fluxbox which contains your patch.

The freeze seems to happen spontaneously (occurs within 1 to 3 weeks). So far I have not been able to find out how to reproduce this bug. There are 8 devices which have this problem. So far it happened about 15 times. The problem is discovered after a user closes the screensaver (xscreensaver) by touching the display. I don't think that xscreensaver is related to the problem.

Currently there is one device in frozen state.

Best regards
Anton

Post by NEURURER.Anton
Hi
I am running fluxbox on a touchscreen device. It works several weeks without problems but then suddenly the main application is not usable anymore because fluxbox grabs the pointer device and does not release it.
I've seen this (twice, I think) but thought it would be due to https://github.com/luebking/fluxbox/commit/fa670bf5a352165baac4f89f83b894a63d5f61cd
(lucky me, then - not my bug ;-)
You do not spot a pattern to reproduce this, did you?
Cheers,
Thomas

------------------------------------------------------------------------------

[Thomas Lübking]

Post by NEURURER.Anton
I do not use any version of fluxbox which contains your patch.

Hardly anybody will - it's not even in git master yet ;-)

Post by NEURURER.Anton
The freeze seems to happen spontaneously (occurs within 1 to 3 weeks). So far I have not been able to find out how to reproduce this bug. There are 8 devices which have this problem. So far it happened about 15 times. The problem is discovered after a user closes the screensaver (xscreensaver) by touching the display. I don't think that xscreensaver is related to the problem.

Smells like fluxbox grabs the pointer, the screensaver grabs the server
(or actively the pointer), fluxbox doesn't receive a button release
(implying an auto-allow of the event) because of this and never allows the
event explicitly.

Is the screensaver triggered im- or explicitly? (ie. for idleness or
from eg. a menu entry)

Cheers,
Thomas

------------------------------------------------------------------------------

[Tim Johnson]

Post by NEURURER.Anton
Hi
I am running fluxbox on a touchscreen device. It works several
weeks without problems but then suddenly the main application is
not usable anymore because fluxbox grabs the pointer device and
does not release it.
[185910.120] client pid 2844 fluxbox
[185910.120] at 179094620 (from passive grab) (device frozen, state 6)
[185910.120] core event mask 0x4
[185910.120] passive grab type 4, detail 0x1, activating key 0
[185910.120] owner-events true, kb 0 ptr 0, confine 0, cursor 0x0
[185910.120] (II) End list of active device grabs
Fluxbox performs a permanent active grab on the mouse device.
Therefore the application does not get mouse events. The only
solution so far is to reboot the touchscreen device.

On a similar note - I find sometimes that the pointer becomes
doubled (as if I were seeing double). It has occurred for me when
I attempt to copy some of what I think is text, but turns out to
be an image, in firefox.

It's no big deal for me, so I'm only mentioning it because of this
topic.

FYI:
I'm running fluxbox 1.3.5 on ubuntu 14.04, 64-bit mac install.
(From repository)

[Thomas Lübking]

Post by Tim Johnson
On a similar note - I find sometimes that the pointer becomes
doubled (as if I were seeing double).

While this could (as any bug) in theory be induced by a frozen pointer,
any visual defect in the cursor is definitively a bug in the server (and
usually in the driver, unless you're using a software cursor. Check
/var/log/Xorg.0.log about this) or XInput (ie. you've an artificial
second input device which usually takes the same position. Sounds weird,
but could be eg. the case if you've a mouse and a touchscreen)

Another option is that some client creates a fake cursor (which is
indeed just an input shaped window) and moves it along the actual one.

Anyway: induced by this fluxbox issue? Maybe. Caused by fluxbox? No way.
the WM doesn't provide the cursor.

Cheers,
Thomas

[NEURURER.Anton]

Smells like fluxbox grabs the pointer, the screensaver grabs the server (or actively the pointer), fluxbox doesn't receive a button release (implying an auto-allow of the event) because of this and never allows the event explicitly.
Is the screensaver triggered im- or explicitly? (ie. for idleness or from eg. a menu entry)

Hi Thomas

The screensaver is triggered implicitly (300 seconds delay time).

If the screensaver is active it performs an active grab on mouse and keyboard:

[308747.389] (II) Printing all currently active device grabs:
[308747.389] Active grab 0x1800000 (core) on device 'Virtual core pointer' (2):
[308747.389] client pid 10624 xscreensaver
[308747.389] at 243482375 (from active grab) (device thawed, state 1)
[308747.389] core event mask 0x3ffc
[308747.389] owner-events true, kb 1 ptr 1, confine 107, cursor 0x1800004
[308747.389] Active grab 0x1800000 (core) on device 'Virtual core keyboard' (3):
[308747.389] client pid 10624 xscreensaver
[308747.389] at 243482375 (from active grab) (device thawed, state 1)
[308747.389] core event mask 0x3
[308747.389] owner-events true, kb 1 ptr 0, confine 0, cursor 0x0
[308747.390] (II) End list of active device grabs

I dont see how fluxbox could perform an active grab at the same time? According to the xlib documentation this should result in an "AlreadyGrabbed" error.

In case the application is not usable any more there is only one active grab (fluxbox) in the xorg log. Then also the screensaver is never activated again.

Best regards
Anton




------------------------------------------------------------------------------

[Thomas Lübking]

Post by NEURURER.Anton
The screensaver is triggered implicitly (300 seconds delay time).

There goes my theory :-(
Yes, that's a "normal" security feature of screensavers.

Post by NEURURER.Anton
I dont see how fluxbox could perform an active grab at the same time?

It doesn't. It's frozen from a passive grab (at least in the log you
provided), ie. probably lacks a
"XAllowEvents(dpy, AsyncPointer, CurrentTime);" somewhere.

Could be the be.time driven call in Window.cc isn't sufficient.
Since you can apparently reproduce this "quite some", can you invoke a
patch (resp. simply alter the call "s/be.time/CurrentTime")?

Cheers,
Thomas

------------------------------------------------------------------------------

[NEURURER.Anton]

Post by Thomas Lübking
Could be the be.time driven call in Window.cc isn't sufficient.
Since you can apparently reproduce this "quite some", can you invoke a patch (resp. simply alter the call "s/be.time/CurrentTime")?

Yes, I can invoke a patch.

Just to be completely sure what you mean:

You want me to replace the line "XAllowEvents(display, ReplayPointer, be.time);" in Window.cc/buttonPressEvent() with "XAllowEvents(display, ReplayPointer, CurrentTime);" ?

Best regards
Anton



------------------------------------------------------------------------------

[Thomas Lübking]

Post by NEURURER.Anton
You want me to replace the line "XAllowEvents(display, ReplayPointer, be.time);" in Window.cc/buttonPressEvent() with "XAllowEvents(display, ReplayPointer, CurrentTime);" ?

Yupp.
It's a very wild guess, though (since we don't even know which
press triggered the freeze)

------------------------------------------------------------------------------

[NEURURER.Anton]

Post by NEURURER.Anton
You want me to replace the line "XAllowEvents(display, ReplayPointer, be.time);" in Window.cc/buttonPressEvent() with "XAllowEvents(display, ReplayPointer, CurrentTime);" ?
Yupp.
It's a very wild guess, though (since we don't even know which press triggered the freeze)

At the moment I am running several devices with your patch. So far no problems occurred.

I am doing some experiments with 2 other devices and I have found out that it is possible to freeze the mouse immediately and permanently if I change "be.time" to "CurrentTime + 10000". According to the xlib manual the time parameter has to be within a specific time frame - otherwise XAllowEvents has no effect.

I think be.time could really be the cause of the problem.

Best regards
Anton

[Thomas Lübking]

Post by NEURURER.Anton
At the moment I am running several devices with your patch. So far no problems occurred.

Cool! =)

Post by NEURURER.Anton
I am doing some experiments with 2 other devices and I have found out that it is possible to freeze the mouse immediately and permanently if I change "be.time" to "CurrentTime + 10000".

Yeah, no - that's the equivalent of "10000" - usually far in the past.
(CurrentTime is 0 and treated specially. The time isn't eg. resolved
dynamically since the async protocol would kill such attempts)

And yes, messing around with timestamps (also on the server) is
incredibly prone to cause such locks.
See https://bugs.kde.org/show_bug.cgi?id=348569 - clusterssh puts junk
into event timestamps and kwin uses event timestamps to update the servertime
(very good for performance, but very attackable as well)

Post by NEURURER.Anton
I think be.time could really be the cause of the problem.

Let's hope so and many thanks for the update.

Cheers,
Thomas

[Thomas Lübking]

Post by NEURURER.Anton
At the moment I am running several devices with your patch. So far no problems occurred.

Sorry for asking back, but I'd like to ensure that the problem finally
disappeared over the last 10 days? (ie. the patch actually fixes it)

Kind regards,
Thomas

------------------------------------------------------------------------------

[NEURURER.Anton]

Sorry for asking back, but I'd like to ensure that the problem finally disappeared over the last 10 days? (ie. the patch actually fixes it)

We are running 5 Displays with the original fluxbox and 5 with the patched version. So far 1 device with the original SW has gone to frozen state. All others work fine so far. It takes quite some time for the problem to occur.

I sent the patch to the devel mail address last week. So far I have not got any response.

We are planning to submit a bug report to debian as soon as the patch gets included in the current development version.

Best regards
Anton