Re: [wmii] blocking on 'wmiir read /event'

Can you please run `wmiir read /event` in a terminal while this is happening
and post the results here after you trigger some events? You'll have to use
"-a /tmp/ns.$USER.:0" or whatever your local equivalent is with wmiir if you
do this over ssh. Also, I'd recommend not using that snap. It wasn't a very
good one.

On Tue, Jun 20, 2006 at 06:57:46PM +1000, Chris Foster wrote:
>Hi everyone,
>
>I'm having a very strange problem with wmiir which has got me totally
>stumped.
>
>When I start wmii, the wmiirc script sometimes fails to read any events.
>For a long while I thought this was just that my changes had broken the
>script (I've never had this problem with the default script), but I've
>found that something as simple as replacing xterm with aterm and Mod1
>with Mod4 produces the effect. Unfortunately the bug is intermittent,
>and I have the feeling that the only reason I haven't seen it with the
>default wmiirc is that I haven't tried running it this way enough times.
>
>In any case, at the moment I have the system running with the problem in
>evidence.
>
>ps confirms that wmiir and wmiirc are indeed running, so I haven't done
>something extremely stupid and crashed wmiirc:
>$ ps -U foster | grep wmii
>23659 tty2 00:00:00 wmii
>23685 tty2 00:00:00 wmiiwm
>23714 tty2 00:00:00 wmiirc
>23713 tty2 00:00:00 wmiir
>
>Putting some logging into wmiirc indicates that the wmiir instance in
>question is the one which sends events to the event loop.
>
>I loaded wmiir into gdb and noticed that it has blocked on the read
>request at transport.c:46
>
>(gdb) bt
>#0 0x00533402 in __kernel_vsyscall ()
>#1 0x001bafa3 in __read_nocancel () from /lib/libc.so.6
>#2 0x0804c169 in ixp_recv_data (fd=3, msg=0x80549c0, msize=4,
> errstr=0x805086c) at transport.c:46
>#3 0x0804c1d6 in ixp_recv_message (fd=3, msg=0x80549c0, msglen=8192,
> errstr=0x805086c) at transport.c:64
>#4 0x08049af8 in ixp_client_do_fcall (c=0x804dbe0) at client.c:23
>#5 0x0804a09e in ixp_client_read (c=0x804dbe0, fid=94852, offset=0,
> result=0x80529c0, res_len=8192) at client.c:159
>#6 0x08049565 in xread (file=0xbf85c83c "/event") at wmiir.c:229
>#7 0x08049940 in main (argc=3, argv=0xbf85bf64) at wmiir.c:305
>
>Putting a breakpoint at transport.c:47 and continuing seems to indicate
>that the read request really has blocked, since the breakpoint is never
>reached. This is after going back to the frozen X and pounding on the
>keys for a while in the hope of generating some events. On the other
>hand, wmiiwm is still running fine, since I can see the status bar being
>updated.
>
>I'm running the latest snapshot at the moment:
>$ wmiiwm -v
>wmiiwm - 20060607, (C)opyright MMIV-MMVI Anselm R. Garbe
>
>However, I first noticed this issue after wmii-3-rc4; I certinally had
>similar symptoms when I tried using wmii-3.
>
>Any ideas? I love wmii but this is driving me a little bit nuts.
>
>Thanks,
>~Chris.
>
>_______________________________________________
>wmii_AT_wmii.de mailing list
>http://wmii.de/cgi-bin/mailman/listinfo/wmii

-- 
Kris Maglione
You are running the GNOME File Manager as root.  As root, you can damage your system, and the File Manager will not stop you.