yeah, that's a great summary, i just do some stuff normally and suddenly i cant
do nothing in X no more. everything updates like normal and i can move the mouse
around, but no clicks or keypresses do anything, and focus doesnt switch when
moving across windows either. it seems to have something to do with mapping new
windows or switching focus i think, but i'm unsure, i havent seen a clear
pattern. if i run chvt 1 externally every click and keypress is processed before
the switch to console and when i switch back to X, everything works normally
without restarting anything, until it grabs again. this is the commit that
introduces the bug:
2003-09-29 12:06 xor
* openbox/event.c: completely rework focus tracking. i hope this is
sane... it seems to be working much better in every way thus far.
i am running current cvs with that and depending commits backed out, confirmed
the bug with clean checkout half an hour ago.. i wish i could be more helpful
than this.
:( this just happened again while i was using firebird but shouldnt grabs be
released if i kill openbox and firebird? also this isnt the same bug as i first
reported i think because those were released when i switched back to console,
but i had to restart x now...
this is still happening for me occasionally. Enough that at work i am having a
hard time continuing to use openbox because i cant get work done. Let me know if
there is anything i can do.
quoting a debian bug for my own reference
"
When focus follows mouse one can cause openbox to freeze completely
by clicking inside a window just as the focus is switching to it
from another window. I've been able to reproduce this consistently
with several different programs, though only a couple of them
(notably mozilla-thunderbird and mozilla-firebird) take long enough
to switch focus for this to happen unintentionally.
To reproduce, the following works easiest for me:
Open a large xterm window alongside mozilla-firebird. With focus
following mouse, place the pointer inside firebird's window on
the edge near the adjacent xterm. Quickly move the pointer to the
xterm window and _immediately_ click with the right mouse button.
Repeat a couple of times if it did not freeze, the timing is quite
critical. It might be easier on a relatively slow computer.
This consistently freezes my openbox so that nothing seems to be
receiving either mouse or keyboard events anymore until I restart
X.
I've been able to reproduce this with various programs and even
dialog windows, once I figured out how to cause it. However, the
the program from which focus is switching away seems to affect
the "sensitivity" of the bug - mozilla-* draw their screen quite
slowly on my computer (1200MHz K7) and I manage to trigger the bug
by accident several times a day when using them. Simpler/faster
programs can take dozens of tries before I can trigger the bug
with their windows, even when deliberately trying to.
It should be noted that the programs whose windows are involved
do NOT freeze as a result of the bug, they keep on running and
displaying text as normal. Also, the pointer moves around the
screen, nothing just responds to it.
"
cannot reproduce; neither debian-sid nor home-build from cvs openbox.
amd k7 1700MHZ; xfree 4.3, nvidia closed source driver;
firefox 0.8+; gnome-panel 2.4.2...
focus follow mouse mode, 300ms focus delay.
mozilla redraws as quickly as any other app; time to switch focus here
does not depend on application.
note to self: this can still be reproduced by enabling netwm in xmms and
doubleclicking the playlist titlebar, hasn't ever happened anywhere else after
the reverted focus code though.
I find that this bug occurs regularly for me and is pretty annoying. I find that
sometimes the mouse hangs and at other times the keyboard also hangs. Normally
to get around it I have two choices. First, I have mapped restarting openbox to
a key combination and that works at times. Interestingly, the times when it
works is when the load monitor (gkrellm) I use is still working (updating the
load). When the load monitor is not updating the screen then the key combination
doesn't work. Next I try to change the virtual console and that always works.
However, the problem is that often I need to use openbox on a remote machine via
vnc and vnc doesn't support changing a remote console. In that case, I have to
restart openbox on the remote machine. When that happens 5 times during the
course of an hour, then I wonder if it is still worth using openbox.
Unfortunately, I haven't found another relatively simple window manager!
I've been seeing this for a while as well, currently using openbox 3.2-5
(unstable debian). It seems to happen more at home (amd64 3200+) than work
(400MHz sewing machine), probably three times in the past week at home and once
at work. Firefox and xmms are always runnin during each occurance; the last one
happened while I was in gimp. I wonder if there's some fighting with gtk...
Lucky me, I'm also having a similar problem caused by nvidia's drivers... ;)
hungerburg mentions focusDelay.. Has anyone had any luck with setting this to a
non-zero? I'm really not feelin at home with ob2 anymore, may give this a try.
I also wonder about X's ability to close any active grabs..
from XFree86(1x):
KEYBOARD
...
Ctrl+Alt+Keypad-Multiply
Not treated specially by default. If the AllowClosedownGrabs
XF86Config-4(5x) file option is specified, this key sequence
kills clients with an active keyboard or mouse grab as well as
killing any application that may have locked the server, nor-
mally using the XGrabServer(3x) Xlib function.
Ctrl+Alt+Keypad-Divide
Not treated specially by default. If the AllowDeactivateGrabs
XF86Config-4(5x) file option is specified, this key sequence
deactivates any active keyboard and mouse grabs.
Section "ServerFlags"
# enable ctrl-alt-kp_multiply (kill window with keyboard/mouse grab)
Option "AllowClosedownGrabs" "true"
# enable ctrl-alt-kp_divide (deactivates keyboard/mouse grab)
Option "AllowDeactivateGrabs" "true"
EndSection
Has anyone tried this? I've got it setup, so we'll see. :P
yeah, i have that configured. If i press ctrl-alt-/ when dragging a window in
openbox, it actually _TRIGGERS_ the bug, amazing. from then on, no keys in X do
anything, including ctrl-alt-+, ctrl-alt-backspace and ctrl-alt-f*. Killing
openbox from console or ssh doesn't make X work again. Maybe someone should ask
the X.org guys about this?
Hm, well at least there's a way to reliably reproduce the problem.
The only focus-related option that made a difference was focusFollows, it did
not occur with click-to-focus (as previously mentioned). I tried this in
openbox2, just for the heck of it, no problem there...
Correction.. I'm able to reproduce with followMouse on or off using ctrl-alt-/.
It seems that openbox will recover (or the bug won't happen) if the mouse
pointer is over the titlebar when you release ctrl-alt-/, something like that
anyway. Guess that's what happened earlier when testing click-to-focus.
Sorry for bugspam. :P
Does anyone have any idea where this is happening? Is it event.c, grab.c or
mouse.c maybe? It's probably none of these and just some buried weirdness fixed
with a one line change. :S
I've tried commenting bits and pieces, sometimes entire cases from event.c, but
the only thing I've found that makes any difference is changing GrabModeSync to
Async in mouse.c:110 (CLIENT_CONTEXT test in mouse_grab_for_client()). I imagine
this is bad as my rxvt seems to get stuck and I'm no longer able to select bits,
but openbox doesn't freak..
I'm totally in over my head here, but my window manager situation is
deteriorating and I'm getting desperate. Openbox 2 is probably the next best
choice, but it's crashy with gmplayer and others, hates Firefox's toolbar
customization thing, and has no layers or fancy action system. :P
I've not seen anyone mention this yet, but a strace just shows both waiting on a
select().
Disregard my previous statments about select(), seems pretty normal for X and
openbox to both be waiting there if nothing is going on.. :P
I've been fooling around with this a bit over the past week when I'm bored. No
real progress to speak of, just some minor bits that may be worth noting.
As already mentioned, a restart can fix this but so can a call to
grab_shutdown(). I modified the SIGUSR2 handler to call this instead of
ob_reconfigure() and setup a sleep && kill before starting the Ctrl+Alt+KP_Minus
bit. Calling grab_shutdown() while a window is moving (or grabbed?) also causes
the problem.
Today, I was fooling with moveresize.c:
void moveresize_event(XEvent *e)
{
g_assert(moveresize_in_progress);
if (e->type == ButtonPress) {
+ XAllowEvents(ob_display, ReplayPointer, CurrentTime);
if (!button) {
This helps with Ctrl+Alt+KP_Minus, but it's not quite right.. Any click to the
window's titlebar after seems to make the window jump to a nearby position,
maybe where the release event occurred or something.. Normally this problem
happens when I'm typing somewhere. I can't see how this would help in those
situations since no window is moving and it seems pretty unlikely that some move
event would be randomly firing. :P
Spent 30 minutes or so looking at FVWM/WindowMaker/other to see if they had any
special bits around button press events and didn't find much.. There were a few
XSync() and while(XCheckTypedEvent()) calls in fvwm I think, which doesn't help...
Maybe it's not mouse-related at all, but in the interactive keyboard grab stuff
instead...
When I trigger the problem with ctrl+alt+/, I have an xterm sitting there with
sleep 15 && killall -USR1 openbox. Openbox comes back when that runs, it's how
I've been doing all my testing..
Doing how exactly? Pressing ctrl-alt-/ is supposed to "fix" the bug, not trigger
it. What i have noticed though is that ctrl-alt-* will trigger the bug.
I'm confused.. In comment 19, you told me how to reproduce the (or a related)
problem.
"If i press ctrl-alt-/ when dragging a window in openbox, it actually _TRIGGERS_
the bug, amazing."
i'm sorry, it does, i was just lucky when i just tried it. however, after you
trigger the bug, can you use the ctrl-alt-{f1-12,*,/} etc keys and does the
mouse cursor change when you move over different areas on the screen? I cannot
and the mouse cursor doesn't change when moving over text areas and neither the
keyboard nor the mouse has any effect whatsoever on anything. Killing openbox
doesn't do anything either, which it SHOULD, when a program dies all it's grabs
are to be released. I'm just confirming that we have the same bug here.
The keyboard doesn't respond at all and the mouse pointer doesn't change when
moving over the root window or xterms.
I'm able to either ssh in and killall -USR1 openbox or setup a sleep && killall
in an xterm prior to ctrl+alt+/, as previously mentioned. I've done this time
and time again, it's never failed to return openbox to a functional state.
Created attachment 526[details]
unlikely fix
maybe worth a try, but I don't believe this is anything close to a proper fix,
if anything it probably just works around the problem as caused by ctrl+alt+/.
I do run ntp, but recently (~6mo) switched from cron+ntpdate to ntpd. The ntpdate jobs ran hourly and I'm relatively certain these "lockups" never happened on the hour.
I'm still running 3.2 with my weirdo patch and have yet to see the problem resurface. However, not everything is well (although I'm unsure if my patch has anything to do with this). Every once in a while I have to killall -USR1 openbox to get menus and just about everything else working, usually happens when I get into work after unlocking my screensaver. I'm also seeing a strange jumping mouse cursor every once in a great while, but more often than locked up menus, a quick flash from the top to the bottom of the workspace.
I was hoping to get away from my patch and try 3.3 to see if either of these went away, but if you're seeing it again, guess I won't be doing that... :P
the thing that is strange, which i probably have mentioned in this bug already but i'm too lazy to search for it, is that it doesn't go away when i kill openbox, i have to restart X... This sort of makes me feel like it's some bug in X triggered by openbox.
Created attachment 1060[details]
maybe?
This seems to "fix" the hang when setting time backwards. It lets you click in programs and use the keyboard. Openbox doesn't start switching focus and stuff until time reaches where you were before though, but it's a lot better than it was before. Can anyone figure out a better place to put these calls or if the arguments should be different? I'm really just guessing here.
(In reply to comment #45)
> Created an attachment (id=1060) [edit]
> maybe?
This, like my patch, also helps with the window drag+control-alt-/ induced hang. Maybe there's some badness in the mainloop functions, the event queue getting backed up due to an unexpected situation, causing openbox to stop processing events and leaving an open key grab.
I'll run with this for a while.
(In reply to comment #45)
> Created an attachment (id=1060) [details]
> maybe?
This patch works nicely for me (mostly). As you pointed out, it stops everything from becomming unresponsive to mouse and keyboard, but still has the issue of not being able to change window fucus. Since I can now enter things into a terminal I can then restart openbox (using 'openbox --replace' since I'm runnig gnome) and that clears things up immediately.
Comment 51Kristoffer Gronlund
2007-02-13 02:11:10 EST
I had this problem, invariably my computer would lock up after leaving it on over night with openbox running. I applied this patch though and now it hasn't locked up since (~4 days).
I couldn't figure out what the reason could be, but now that you've talked about it here, it seems reasonable that it would be related to timing. I have this problem with my computer that the clock runs a bit fast, so it gets reset back by ntpd once in a while...
Comment 52Kristoffer Gronlund
2007-02-16 01:55:03 EST
I am now convinced that this has something to do with the time shifting back - I just got the lockup after starting up my computer, when connecting to the internet. That is, when ntpd updates the time.
While I'm not confident it has anything to do w/ time going backwards, it does seem somehow time related.
I have 3 systems all running Ubuntu + openbox 3.3 and when the hang occurs on my desktop, I normally go for my laptop, which upon resuming from suspend also will lock up. Today, I got the hang on my work-desktop, and saw the same problem on my laptop. Then when I got home, I found my desktop hung as well.
So when the hang occurs, it frequently happens on multiple systems near the same time, usually (not not always) after entering my password in from gnome-screensaver.
Created attachment 1277[details]
use CurrentTime
I'm not really familiar with X11 or it's event handling, but if all of these problems are somehow related to clock skew, would it be better to pass CurrentTime to these functions (instead of event_lasttime)? ob2 doesn't seem to use it's 'last_time' variable much...
The patch applies to 3.3.1 and compiles ok. I've been using it for the last few minutes and haven't seen anything out of the ordinary, but I also haven't attempted any of the previously mentioned ways of hanging openbox (ctrl-alt-/, etc).
as far as i can tell, this bug is fixed in SVN. i can change my clock forward and backward by hours at a time and it won't freeze anymore. also the given method of reproducing the freeze with firefox is not freezing anything for me.
please do let me know if it's not fixed, but i'm going to mark this bug resolved for now.
Sorry, but it seems this bug is still around.
My system just run rdate, and Openbox froze in the well known fashion.
I tested setting the clock forward/backward by weeks, and that didn't break anything though.
What I'm now seeing _could_ be another bug, but I guess that's doubtful? And yes, I'm running Openbox SVN trunk ;)
At this point in time, I think we've done about everything we can for this bug. X's clock should not go backward even if your system's time does. If you can figure out a very reproducable way to cause it still, I can try look at it. But otherwise, don't set your clock backwards! Run ntpd.
I'm going to mark this WONTFIX unless you can find something really reproducable.
Step to reproduce (under Suse 10.2):
- Run the openbox under vnc:
* Go to ~/.vnc
* Modify the xstartup file to use openbox (exec openbox)
* Run the vncserver
* Connect to vncserver using vncviewer
- Change the time backward (e.g. from 15:00 to 14:00)
- Result: the mouse and keyboard will stop responding
And it starts responding when you kill Openbox? Please let me know.
I think it's probably other things freezing besides Openbox. We check timestamps to ensure we never Ungrab with time earlier than the last Grab now.
You're going to need to provide a little more context as to how to reproduce it, if it's ever going to stop. If you don't just stop changing your clock backwards anyhow..
We'll need to know exactly what you did when the freeze occured. Did the keyboard stop responding, or the mouse? Etc..
The clock is never intentionally set to backward.
The problem comes when NTP is used, i.e. when the NTP connection is lost in short time (e.g. due to net traffic or some small delay in the service).
With this NTP connection, if 1000 clients are connected to one NTP server, and NTP server gives some delay at certain time, then all 1000 clients will possibly get the clock changed to their local battery time.
As a result, when the clock are switched to backward, all of them will be frozen.
Keyboard: stop responding
Mouse: can move the pointer but cannot click.
Well the only case I can see causing this is when the x server moves its clock backwards between it sending us an event, and us calling XUngrabKeyboard. Which is just totally ridiculous of x.org.
If you are compiling from source, I'd love to hear if this actually makes the problem go away or not:
Index: openbox/grab.c
===================================================================
--- openbox/grab.c (revision 7282)
+++ openbox/grab.c (revision 7283)
@@ -84,7 +84,7 @@
ret = TRUE;
} else if (kgrabs > 0) {
if (--kgrabs == 0) {
- XUngrabKeyboard(ob_display, ungrab_time());
+ XUngrabKeyboard(ob_display, CurrentTime);
}
ret = TRUE;
}
@@ -113,7 +113,7 @@
ret = TRUE;
} else if (pgrabs > 0) {
if (--pgrabs == 0) {
- XUngrabPointer(ob_display, ungrab_time());
+ XUngrabPointer(ob_display, CurrentTime);
}
ret = TRUE;
}
Thanks
Reading back, I thought you had mentioned what version of Openbox you are using. But you don't.
Are you using 3.3.995, or 3.3.1? We think it's fixed in 3.3.995. I can't get Openbox to freeze by moving the clock around at all.
I also wonder about X's ability to close any active grabs.. from XFree86(1x): KEYBOARD ... Ctrl+Alt+Keypad-Multiply Not treated specially by default. If the AllowClosedownGrabs XF86Config-4(5x) file option is specified, this key sequence kills clients with an active keyboard or mouse grab as well as killing any application that may have locked the server, nor- mally using the XGrabServer(3x) Xlib function. Ctrl+Alt+Keypad-Divide Not treated specially by default. If the AllowDeactivateGrabs XF86Config-4(5x) file option is specified, this key sequence deactivates any active keyboard and mouse grabs. Section "ServerFlags" # enable ctrl-alt-kp_multiply (kill window with keyboard/mouse grab) Option "AllowClosedownGrabs" "true" # enable ctrl-alt-kp_divide (deactivates keyboard/mouse grab) Option "AllowDeactivateGrabs" "true" EndSection Has anyone tried this? I've got it setup, so we'll see. :PDisregard my previous statments about select(), seems pretty normal for X and openbox to both be waiting there if nothing is going on.. :P I've been fooling around with this a bit over the past week when I'm bored. No real progress to speak of, just some minor bits that may be worth noting. As already mentioned, a restart can fix this but so can a call to grab_shutdown(). I modified the SIGUSR2 handler to call this instead of ob_reconfigure() and setup a sleep && kill before starting the Ctrl+Alt+KP_Minus bit. Calling grab_shutdown() while a window is moving (or grabbed?) also causes the problem. Today, I was fooling with moveresize.c: void moveresize_event(XEvent *e) { g_assert(moveresize_in_progress); if (e->type == ButtonPress) { + XAllowEvents(ob_display, ReplayPointer, CurrentTime); if (!button) { This helps with Ctrl+Alt+KP_Minus, but it's not quite right.. Any click to the window's titlebar after seems to make the window jump to a nearby position, maybe where the release event occurred or something.. Normally this problem happens when I'm typing somewhere. I can't see how this would help in those situations since no window is moving and it seems pretty unlikely that some move event would be randomly firing. :P Spent 30 minutes or so looking at FVWM/WindowMaker/other to see if they had any special bits around button press events and didn't find much.. There were a few XSync() and while(XCheckTypedEvent()) calls in fvwm I think, which doesn't help... Maybe it's not mouse-related at all, but in the interactive keyboard grab stuff instead...i'm sorry, it does, i was just lucky when i just tried it. however, after you trigger the bug, can you use the ctrl-alt-{f1-12,*,/} etc keys and does the mouse cursor change when you move over different areas on the screen? I cannot and the mouse cursor doesn't change when moving over text areas and neither the keyboard nor the mouse has any effect whatsoever on anything. Killing openbox doesn't do anything either, which it SHOULD, when a program dies all it's grabs are to be released. I'm just confirming that we have the same bug here.Created attachment 526 [details] unlikely fix maybe worth a try, but I don't believe this is anything close to a proper fix, if anything it probably just works around the problem as caused by ctrl+alt+/.Created attachment 1060 [details] maybe? This seems to "fix" the hang when setting time backwards. It lets you click in programs and use the keyboard. Openbox doesn't start switching focus and stuff until time reaches where you were before though, but it's a lot better than it was before. Can anyone figure out a better place to put these calls or if the arguments should be different? I'm really just guessing here.Created attachment 1277 [details] use CurrentTime I'm not really familiar with X11 or it's event handling, but if all of these problems are somehow related to clock skew, would it be better to pass CurrentTime to these functions (instead of event_lasttime)? ob2 doesn't seem to use it's 'last_time' variable much... The patch applies to 3.3.1 and compiles ok. I've been using it for the last few minutes and haven't seen anything out of the ordinary, but I also haven't attempted any of the previously mentioned ways of hanging openbox (ctrl-alt-/, etc).Well the only case I can see causing this is when the x server moves its clock backwards between it sending us an event, and us calling XUngrabKeyboard. Which is just totally ridiculous of x.org. If you are compiling from source, I'd love to hear if this actually makes the problem go away or not: Index: openbox/grab.c =================================================================== --- openbox/grab.c (revision 7282) +++ openbox/grab.c (revision 7283) @@ -84,7 +84,7 @@ ret = TRUE; } else if (kgrabs > 0) { if (--kgrabs == 0) { - XUngrabKeyboard(ob_display, ungrab_time()); + XUngrabKeyboard(ob_display, CurrentTime); } ret = TRUE; } @@ -113,7 +113,7 @@ ret = TRUE; } else if (pgrabs > 0) { if (--pgrabs == 0) { - XUngrabPointer(ob_display, ungrab_time()); + XUngrabPointer(ob_display, CurrentTime); } ret = TRUE; } Thanks