[thhsieh: Re: Endless events]
----- Forwarded message from Tung-Han Hsieh <thhsieh> -----
Date: Thu, 15 Jul 1999 22:21:06 +0800
From: Tung-Han Hsieh <thhsieh>
To: xcin@linux.org.tw
Subject: Re: Endless events
X-Mailer: Mutt 0.95.4us
In-Reply-To: <19990703031605.A16713@lot.eng.ohio-state.edu>; from Yung-Ching Hsiao on Sat, Jul 03, 1999 at 03:16:05AM -0400
On Sat, Jul 03, 1999 at 03:16:05AM -0400, Yung-Ching Hsiao wrote:
> On Jul 03(Sat) 09:40AM, hashao wrote:
> > Okey, I come across it now. It seems like the xcin server received
> > some kind of ClientMessage (I assume that the xcin selected the event).
> > Then the xcin filtered the event and sent out some composed char. In
> > return, it got another ClientMessage, and it filtered, composed and the
> > thing goes on and on and on. Maybe some race condition happened.
>
> This seems like some kind of bad interaction between the XFilterEvent
> machanism and the Shade (Shrink to Title bar) feature of the window manager.
> Maybe you should print out the type of XClientMessage to check what has
> been filtered:
>
> XNextEvent(&ev)
> if (XFilterEvent(&ev)==Filtered) {
> if (ev.any.type==ClientMessage)
> dump_clientmessage(&ev);
> continue;
> }
Hello,
I have locate this problem. It should be the bug of rxvt-2.6.0.
The problem is: When we iconfy rxvt, it will preriodically run
the function: cmd_getc() (I don't know why), and in this function
it will call IMSendSpot() function, and it will send XGetICValues()
so that xcin will receive the ClientMessage continueously.
This problem has other side effect. If we terminate the xcin, then
all the iconfied rxvt processes will be terminated, too. On the
other hand, if rxvt is now in the keyboard focus, and then we kill
xcin, rxvt will fall into the loops to call cmd_getc(), and before
it can receive the message from Xlib that xcin is gone away through
the XNextEvent/XFilterEvent, it goes into IMSendSpot() and call
XGetICValues() again, and again it crashed. I think this might be
the racing condition. Unfortunately it false in the fvwm95 WM.
Here I provide a small patch for rxvt-2.6.0/src/command.c to solve
this problem:
=========================================================================
--- command.c.orig Thu Jul 15 20:13:06 1999
+++ command.c Thu Jul 15 21:55:57 1999
@@ -1673,7 +1673,9 @@
scr_refresh(refresh_type);
scrollbar_show(1);
#ifdef USE_XIM
+/*
IMSendSpot();
+*/
#endif
}
}
@@ -3410,7 +3412,7 @@
XVaNestedList preedit_attr;
XIMStyle input_style;
- if (Input_Context == NULL)
+ if (Input_Context == NULL || ! TermWin.focus)
return;
else {
XGetICValues(Input_Context, XNInputStyle, &input_style, NULL);
==========================================================================
One is that just let cmd_getc() function don't call IMSendSpot(), but
I am not sure if this way is acceptable or not. The second change is
in IMSendSpot(), to test that if rxvt is not in the IC focus status,
then don't execute the codes in IMSendSpot().
Please test it. :-))
T.H.Hsieh
----- End forwarded message -----
Reply to: