Not the original poster, but I have what looks like the same problem using IceWM 1.3.1 on Debian Sid.
IceWM was compiled from source using ./configure (no options) - make - #make install.
To recreate problem -
After IceWm is started, open two instances of rxvt (/usr/bin/rxvt-xterm -geometry 135x25+101+638 -bg ivory -fg blue3 -fn 6x13 +sr -sl 2000) and try to alt-tab between the two terminals.
Something hangs/freezes. Keyboard is unresponsive (can't ctrl-alt-backspace to kill X, can't ctrl-alt Fx to get to a console). Video is pretty much unresponsive (clock display stops updating). Mouse can be moved around and pointer also moves around. Mouse clicking on anything is unresponsive.
Tasks that were running, continue to run. for example, downloads via wget continue until finished. mplayer continues playing audio files until finished.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd say it's much more than just the "window change" issue.
Sorry for the huge delay in noticing this issue report, but here I am,
hoping to be able to share some (hopefully) useful info that could aid
IceWM developers in determining the cause of these hiccups.
We had much trouble over a month ago when we tried to update
our development workstations:
* Debian: xserver-xorg-core 2:1.4.1~git20071119-1
* Fedora: xorg-x11-server* 1.4.99.1-0.10.fc9
IceWM (both 1.2.x and 1.3.x CVS trees) locked the Xserver up [1]
(pseudo)randomly, but after a few tests, here's the most simplistic
way we found to reproduce it: trigger SysDialog (Ctrl+Alt+Del) or
SysMenu (Ctrl+Esc) and try to select something (using any input
device, it worked both by "keyboard" or "mouse").
[1] AFAICR the "lock up" was pretty similar to what the previous poster
mentioned: screen freeze, input devices freeze, X consuming 100% CPU.
Xorg logs were showing lots and lots of these two lines:
"
tossed event which came in late
mieqEnequeue: out-of-order valuator event; dropping.
"
My guess is this problem originates somewhere around Xorg's redesign
regarding input devices... but we were way too pissed to start digging
through their sources at the time... and downgraded+blacklisted xorg* :(
'HTH
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I get similar hangs for most Alt-key combinations (Alt-Tab, Alt-space, ...). Software versions: IceWM 1.2.32 and 1.2.34 on Xorg server 1.4.0.90. On the SAME system, Alt-Tab works flawlessly in KDE's window manager and in OpenBox. Does not look like an Xorg problem to me ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also got them with XOrg 1.4.0.90 pristine. For the time being, I'm back to 1.4.0, where it never occurred. I first thought it was a problem with the new ATI driver (6.7.197), but disabling DRI or reverting to 6.7.196 didn't help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you try:
1. compile icewm with debug (configure --enable-debug)
2. reproduce the problem
3. switch to console
4. attach with gdb: gdb /path/to/icewm <pid>
5. get the backtrace (where)
6. list the code of current function (list)
And send me the output from gdb.
Does this occur randomly or when some app is used?
It never happened to me, so I'd like as much information as possible
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Me ? I can't because I don't have any way to log in from another computer. When it happens, the only solution is to issue /sbin/reboot, what I can do pressing some keys in a gamepad. A /bin/killall -9 X freezes the mouse pointer. Before, I can move the mouse pointer, but that's all. It's like an "I" everywhere in the screen and doesn't do anything. The clock in IceWM also stops, but any activity (downloads...) continues.
Sending a '/bin/killall -QUIT icewm' from joyd didn't do anything. I could still move the mouse pointer. And there was no core file after I rebooted (I recompiled 1.3.2 with --enable-debug and ulimit is unlimited).
Marko, it's definitely something in XOrg 1.4.0.90, no ? When I tested with it, a simple Ctrl+Esc in IceWM produced the lockup, what doesn't happen in 1.4.0.
("nobody" here, but not the one who has a gamepad -- maybe I should get me finally an SF login)
It is certainly NOT the fault of Xorg. Using the SAME Alt- and Ctrl-key combinations, all other window managers work flawlessly with Xorg 1.4.0.90.
Maybe the following observations help. Using Alt-Tab, the hang occurs when releasing the Alt key. I can tab as long as I want without problems, until I release the Alt key -- then it hangs: The Alt-Tab dialogue box stays on screen but is completely unresponsive, as is everything else except for the mouse pointer and the Alt-SysReq-K key combination.
Interestingly, Alt-Esc does NOT produce the hang. Alt-Esc also switches between windows, but, differently from Alt-Tab, does not use a dialogue.
Together, these observations suggest that the hang is somehow related to the REMOVAL of the dialog box from the screen. The dialog box is to be removed in Alt-Tab as soon as one releases the Alt key, and exactly then the crash happens. There is no dialogue box to be removed in Alt-Esc, and in fact Alt-Esc does not crash. Does that sound plausible?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I forgot to say that it's the same with the windows menu (Alt-Spacebar). The menu can be invoked and used (cursor up, cursor down) without problems. But as soon as one selects a menu entry (Enter key, or mouseclick), or tries to close the menu with Escape, the system hangs.
As with the Alt-Tab dialogue box, the hang occurs when something needs to be REMOVED from the screen (although this time it is a menu).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ctrl-Alt-Function keys and Ctrl-Alt-Backspace don't work. Only the Alt-SysRq-K combination works (and afterwards, Ctrl-Alt-Del).
IceWM wouldn't compile with --enable-debug (GCC 4.2.2). So I did the next-best thing and compiled it with no options to ./configure and no CFLAGS or CXXFLAGS set in the environment.
Then I ran "sleep 60 && killall -QUIT icewm && sync && reboot" in one console, and "ulimit -c unlimited" and "startx" in another console. I then triggered the bug and waited for the reboot. This did NOT produce a core file. So I repeated the procedure, but replaced "killall -QUIT icewm" by "killall -ABRT icewm". This produced a core file.
Now there are two problems, the first is a core file without any debug symbols, and the second is my lack of knowledge what to do with it. I started gdb and told it "core-file core". The output is:
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by 'icewm'.
Program terminated with signal 6, Aborted.
#0 0xb7ef2410 in __kernel_vsyscall ()
which is probably not informative at all. I also found gdb's "backtrace" command, and here the output is:
#0 0xb7ef2410 in __kernel_vsyscall ()
#1 0xb7a5d63d in ?? ()
Can anything else be done before I delete the file?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried the above steps with an IceWM compiled with --enabled-debug, but there's nothing in the backtrace:
#0 0xb7a5e828 in ___newselect_nocancel () from /lib/libc.so.6
#1 0xb797b44f in ?? () from /usr/X11R6/lib/libxcb.so.1
#2 0x00000006 in ?? ()
#3 0xbfa9e6dc in ?? ()
#4 0xbfa9e65c in ?? ()
#5 0x00000000 in ?? ()
Does this mean everything is from XOrg ? XOrg is stripped.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i'm using slackware current and i'm experiencing the same hang on icewm...
my system details are: kernel 2.6.24.3 (slackware current standard kernel), gcc 4.2.3, glibc 2.7, xorg 1.4.0.90, nvidia x-driver (nv x-driver didn't change a thing).
if you need to know something else, just ask me. :)
here is now the backtrace from my icewm with enabled debug:
#0 0x08092f76 in YFrameWindow::layoutShape (this=0x823a460) at decorate.cc:252
#1 0x080936a1 in YFrameWindow::layoutShape (this=0x823a460) at decorate.cc:295
#2 0x0808df18 in YFrameWindow::snapTo (this=0x849e520, wx=@0x849e520, wy=@0xbf8ae298) at movesize.cc:148
#3 0x08147071 in ?? ()
#4 0x0849e520 in ?? ()
#5 0x0849e520 in ?? ()
#6 0xbf8ae298 in ?? ()
#7 0x081d1354 in ?? ()
#8 0x081fed98 in ?? ()
#9 0x0849e520 in ?? ()
#10 0xbf8ae6f8 in ?? ()
#11 0x0808699b in Graphics::copyPixmap (this=0x849e520, p=@0x849e520, x=0, y=4194458, w=8, h=0, dx=0, dy=0) at ypaint.h:211
Backtrace stopped: frame did not save the PC
does this help you? do you need more? or is it definitely a x.org-bug?
pls help. this is annoying... :(
raShMan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: NO
Could you provide more information about this bug and the version of IceWM you are using? Is there any way to reproduce the behaviour?
Logged In: NO
Not the original poster, but I have what looks like the same problem using IceWM 1.3.1 on Debian Sid.
IceWM was compiled from source using ./configure (no options) - make - #make install.
To recreate problem -
After IceWm is started, open two instances of rxvt (/usr/bin/rxvt-xterm -geometry 135x25+101+638 -bg ivory -fg blue3 -fn 6x13 +sr -sl 2000) and try to alt-tab between the two terminals.
Something hangs/freezes. Keyboard is unresponsive (can't ctrl-alt-backspace to kill X, can't ctrl-alt Fx to get to a console). Video is pretty much unresponsive (clock display stops updating). Mouse can be moved around and pointer also moves around. Mouse clicking on anything is unresponsive.
Tasks that were running, continue to run. for example, downloads via wget continue until finished. mplayer continues playing audio files until finished.
Logged In: YES
user_id=213635
Originator: NO
I'd say it's much more than just the "window change" issue.
Sorry for the huge delay in noticing this issue report, but here I am,
hoping to be able to share some (hopefully) useful info that could aid
IceWM developers in determining the cause of these hiccups.
We had much trouble over a month ago when we tried to update
our development workstations:
* Debian: xserver-xorg-core 2:1.4.1~git20071119-1
* Fedora: xorg-x11-server* 1.4.99.1-0.10.fc9
IceWM (both 1.2.x and 1.3.x CVS trees) locked the Xserver up [1]
(pseudo)randomly, but after a few tests, here's the most simplistic
way we found to reproduce it: trigger SysDialog (Ctrl+Alt+Del) or
SysMenu (Ctrl+Esc) and try to select something (using any input
device, it worked both by "keyboard" or "mouse").
[1] AFAICR the "lock up" was pretty similar to what the previous poster
mentioned: screen freeze, input devices freeze, X consuming 100% CPU.
Xorg logs were showing lots and lots of these two lines:
"
tossed event which came in late
mieqEnequeue: out-of-order valuator event; dropping.
"
My guess is this problem originates somewhere around Xorg's redesign
regarding input devices... but we were way too pissed to start digging
through their sources at the time... and downgraded+blacklisted xorg* :(
'HTH
Logged In: YES
user_id=213635
Originator: NO
Here are two more reports from Debian's queue:
"Complete lockup with atl+tab" - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452197
"Complete lockup with Ctrl+Esc" - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452002
Logged In: NO
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451989 and friends for more details.
Logged In: YES
user_id=1814
Originator: NO
seems like xorg problem, closing
Logged In: NO
I get similar hangs for most Alt-key combinations (Alt-Tab, Alt-space, ...). Software versions: IceWM 1.2.32 and 1.2.34 on Xorg server 1.4.0.90. On the SAME system, Alt-Tab works flawlessly in KDE's window manager and in OpenBox. Does not look like an Xorg problem to me ...
Logged In: YES
user_id=96658
Originator: NO
I also got them with XOrg 1.4.0.90 pristine. For the time being, I'm back to 1.4.0, where it never occurred. I first thought it was a problem with the new ATI driver (6.7.197), but disabling DRI or reverting to 6.7.196 didn't help.
Logged In: YES
user_id=1814
Originator: NO
Can you try:
1. compile icewm with debug (configure --enable-debug)
2. reproduce the problem
3. switch to console
4. attach with gdb: gdb /path/to/icewm <pid>
5. get the backtrace (where)
6. list the code of current function (list)
And send me the output from gdb.
Does this occur randomly or when some app is used?
It never happened to me, so I'd like as much information as possible
Logged In: NO
Me ? I can't because I don't have any way to log in from another computer. When it happens, the only solution is to issue /sbin/reboot, what I can do pressing some keys in a gamepad. A /bin/killall -9 X freezes the mouse pointer. Before, I can move the mouse pointer, but that's all. It's like an "I" everywhere in the screen and doesn't do anything. The clock in IceWM also stops, but any activity (downloads...) continues.
Marko, reading the Debian bug reports and https://bugs.freedesktop.org/show_bug.cgi?id=13688 , it's likely a bug in XOrg. Maybe one just easier to trigger with IceWM ?
Logged In: YES
user_id=1814
Originator: NO
Don't kill X.
Try instead doing this:
be sure to have core dumps enabled:
ulimit -c unlimited # before starting icewm
killall -QUIT icewm
this should generate a core file.
Then reboot and examine the core file after reboot with gdb.
Logged In: NO
Sending a '/bin/killall -QUIT icewm' from joyd didn't do anything. I could still move the mouse pointer. And there was no core file after I rebooted (I recompiled 1.3.2 with --enable-debug and ulimit is unlimited).
Marko, it's definitely something in XOrg 1.4.0.90, no ? When I tested with it, a simple Ctrl+Esc in IceWM produced the lockup, what doesn't happen in 1.4.0.
I compiled both from
http://xorg.freedesktop.org/releases/individual/xserver/
with
--disable-config-dbus --disable-config-hal --disable-dmx --disable-xprint --enable-install-setuid --with-mesa-source=/usr/local/src/CVS/X11/
XOrg/mesa (Mesa is 7.0.2).
BTW, it also locked up with a recent IceWM 1.2 I was using.
Logged In: NO
("nobody" here, but not the one who has a gamepad -- maybe I should get me finally an SF login)
It is certainly NOT the fault of Xorg. Using the SAME Alt- and Ctrl-key combinations, all other window managers work flawlessly with Xorg 1.4.0.90.
Maybe the following observations help. Using Alt-Tab, the hang occurs when releasing the Alt key. I can tab as long as I want without problems, until I release the Alt key -- then it hangs: The Alt-Tab dialogue box stays on screen but is completely unresponsive, as is everything else except for the mouse pointer and the Alt-SysReq-K key combination.
Interestingly, Alt-Esc does NOT produce the hang. Alt-Esc also switches between windows, but, differently from Alt-Tab, does not use a dialogue.
Together, these observations suggest that the hang is somehow related to the REMOVAL of the dialog box from the screen. The dialog box is to be removed in Alt-Tab as soon as one releases the Alt key, and exactly then the crash happens. There is no dialogue box to be removed in Alt-Esc, and in fact Alt-Esc does not crash. Does that sound plausible?
Logged In: NO
I forgot to say that it's the same with the windows menu (Alt-Spacebar). The menu can be invoked and used (cursor up, cursor down) without problems. But as soon as one selects a menu entry (Enter key, or mouseclick), or tries to close the menu with Escape, the system hangs.
As with the Alt-Tab dialogue box, the hang occurs when something needs to be REMOVED from the screen (although this time it is a menu).
Logged In: YES
user_id=1814
Originator: NO
Can you switch to console using Ctrl+Alt+F1 or shutdown Xorg using Ctrl+Alt+Backspace.
If no, it's almost certainly an Xorg bug.
If yes, please try getting the coredump of icewm using the way I described, except use SIGABRT instead of SIGQUIT.
Logged In: YES
user_id=579925
Originator: NO
(Looks like I already HAVE an SF account, whow!)
Ctrl-Alt-Function keys and Ctrl-Alt-Backspace don't work. Only the Alt-SysRq-K combination works (and afterwards, Ctrl-Alt-Del).
IceWM wouldn't compile with --enable-debug (GCC 4.2.2). So I did the next-best thing and compiled it with no options to ./configure and no CFLAGS or CXXFLAGS set in the environment.
Then I ran "sleep 60 && killall -QUIT icewm && sync && reboot" in one console, and "ulimit -c unlimited" and "startx" in another console. I then triggered the bug and waited for the reboot. This did NOT produce a core file. So I repeated the procedure, but replaced "killall -QUIT icewm" by "killall -ABRT icewm". This produced a core file.
Now there are two problems, the first is a core file without any debug symbols, and the second is my lack of knowledge what to do with it. I started gdb and told it "core-file core". The output is:
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by 'icewm'.
Program terminated with signal 6, Aborted.
#0 0xb7ef2410 in __kernel_vsyscall ()
which is probably not informative at all. I also found gdb's "backtrace" command, and here the output is:
#0 0xb7ef2410 in __kernel_vsyscall ()
#1 0xb7a5d63d in ?? ()
Can anything else be done before I delete the file?
Logged In: YES
user_id=1814
Originator: NO
Can you post the --enable-debug build errors?
Instead of 'configure --enable-debug', can you change src/Makefile:
replacing the -O2 (or similiar) with -g in CXXFLAGS line and rebuilding.
Note: if you can't shutdown X with Ctrl+Alt+Backspace or switch to console, this is an X server bug almost certainly.
Logged In: YES
user_id=579925
Originator: NO
Here are the "./configure --enable-debug" build errors with GCC 4.2.2. It says something about line 10010 in dwarfout.c, but I cannot find that file.
I'll try the src/Makefile flags next.
[~/test/icewm-1.2.34] make
make[1]: Entering directory `/root/test/icewm-1.2.34/src'
CXX yapp.o
yapp.cc:472: internal compiler error: in reference_to_unused, at dwarf2out.c:10010
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [yapp.o] Error 1
make[1]: Leaving directory `/root/test/icewm-1.2.34/src'
make: *** [base] Error 2
[~/test/icewm-1.2.34]
Logged In: YES
user_id=96658
Originator: NO
I tried the above steps with an IceWM compiled with --enabled-debug, but there's nothing in the backtrace:
#0 0xb7a5e828 in ___newselect_nocancel () from /lib/libc.so.6
#1 0xb797b44f in ?? () from /usr/X11R6/lib/libxcb.so.1
#2 0x00000006 in ?? ()
#3 0xbfa9e6dc in ?? ()
#4 0xbfa9e65c in ?? ()
#5 0x00000000 in ?? ()
Does this mean everything is from XOrg ? XOrg is stripped.
Logged In: YES
user_id=826307
Originator: NO
Me too with IceWM 1.2.34 on Gentoo. I have to kill X11.
Window menu (that one with Move, Maximize, Close, ...) also hangs my IceWM.
Logged In: NO
This patch solved the problem for me:
https://bugs.freedesktop.org/show_bug.cgi?id=13511#c1
Logged In: YES
user_id=2011173
Originator: NO
hey out there,
i'm using slackware current and i'm experiencing the same hang on icewm...
my system details are: kernel 2.6.24.3 (slackware current standard kernel), gcc 4.2.3, glibc 2.7, xorg 1.4.0.90, nvidia x-driver (nv x-driver didn't change a thing).
if you need to know something else, just ask me. :)
here is now the backtrace from my icewm with enabled debug:
#0 0x08092f76 in YFrameWindow::layoutShape (this=0x823a460) at decorate.cc:252
#1 0x080936a1 in YFrameWindow::layoutShape (this=0x823a460) at decorate.cc:295
#2 0x0808df18 in YFrameWindow::snapTo (this=0x849e520, wx=@0x849e520, wy=@0xbf8ae298) at movesize.cc:148
#3 0x08147071 in ?? ()
#4 0x0849e520 in ?? ()
#5 0x0849e520 in ?? ()
#6 0xbf8ae298 in ?? ()
#7 0x081d1354 in ?? ()
#8 0x081fed98 in ?? ()
#9 0x0849e520 in ?? ()
#10 0xbf8ae6f8 in ?? ()
#11 0x0808699b in Graphics::copyPixmap (this=0x849e520, p=@0x849e520, x=0, y=4194458, w=8, h=0, dx=0, dy=0) at ypaint.h:211
Backtrace stopped: frame did not save the PC
does this help you? do you need more? or is it definitely a x.org-bug?
pls help. this is annoying... :(
raShMan