I have been using wmii for the past few weeks, and overall I have been
quite happy with it. But I have stumbled across a rather annoying bug with
wmiirc. After I have been running wmii for anywhere between a day and
several days, it will stop responding to keyboard inputs. I blame this on
wmiirc as if I kill it and then start a new one from an open shell, then
keyboard input starts working again. This has happened multiple times.
While wmiirc is locked up, I can still select different, visible windows
with my mouse, but that is about all I can do. Clicking on the status bar
at the bottom of the screen to switch the displayed tag does nothing. If I
run 'wmiir read /event', then I can see keyboard events (and others) being
sent, o it appears that wmii itself it working fine. It is as if that
while/case statement in wmiirc that is reading from /events has jammed.
My wmiirc is pretty basic and standard (see attached) so I don't see
anything in there that could be causing the problem. I am observing this
on both my desktop and laptop, both Debian 3.0 (woody) systems. I grabbed
the source to the 3.0-1 package in Debian testing and recompiled it
without issue for my systems.
I have run strace against wmiirc when it has jammed, but all I (ever) get
is 'wait4(-1'. I currently have strace running against the restarted
wmiirc and logging to a file. When wmiirc locks up again, I will send the
history immediately before the lock up to the list.
Anyone seen this happen before? Anyone have any idea what is going
on? Thanks!
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:08:53 UTC