I have following problem:

Sometimes (really often) when i move a window, fvwm stops working for a while.
I can’t move any window, i can’t type some characters on any window, fvwm recognizes the mouse moves, and the mouse-sign is moving on the screen.
But no klicks are recognized. Wheater from the mouse nor from the keyboard.
Every others is working normal.

I can change to the VT1 to 6. And in .xsession-errors i get a message, when fvwm starts working normal again:

[fvwm][FlushMessageQueue]: <> Failed to write descriptor to ‘/usr/bin/icedove’:

  • select rc=0
  • terminate signal=N

I tried it out. This all happens only when icedove is running.

Is this a problem of icedove or fvwm???

greez scientific

PS: System ist Debian Lenny 64-bit,
fvwm --version
fvwm 2.5.27 (from cvs) compiled on Jul 16 2008 at 15:34:39
with support for: ReadLine, RPlay, Stroke, XPM, PNG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS
from the snapshot: fvwm-snap-20080716.tar.gz

So from that, I can tell you have FvwmCommandS running – I too have seen this issue, and will look into fixing it. Unless you use FvwmCommand, I would suggest stopping FvwmCommandS from running.

– Thomas Adam

Hmmm Thx!

But i don’t know, if i have FvwmCommandS running. There are only this Lines:

  • “FvwmCommand” Exec xterm -e man FvwmCommand
  • “Command.pm” FvwmCommand.pm
  • “CommandS” FvwmCommandS
  • “Command.sh” FvwmCommand.sh

in my .fvwm2rc-file, which adds this Modules to a Menu. Not more.

Where can i find out, if i use this Module?


no ideas?

this bug makes me crazy… :frowning:

					/* Wait until the pipe accepts further
					 * input */
					timeout.tv_sec = moduleTimeout;
					timeout.tv_usec = 0;
					FD_SET(channel, &writeSet);
					rc = fvwmSelect(
						channel + 1, NULL, &writeSet,
						NULL, &timeout);
					/* retry if select() failed with EINTR
				} while ((rc < 0) && !isTerminated &&
					 (errno == EINTR));

Try setting:

ModuleTimeout 1

I can reproduce this, but not consistently.

– Thomas Adam

thx, this is a good workaround.
But i don’t know, what this lines of code mean… is this the part, where the bug is located?

I also could not reproduce ist consistently. Sometime ist happens, sometimes not…