Issue565

classification
Title XEmacs hangs in xcb_wait_for_event
Type defect Module core code 21.5
Severity hang Platform unix, xt
Keywords Nosy List FKtPp, stephen
explanation
process
These controls should only be changed by committers and tracker administrators.
Status verified   Reason
Superseder  
Priority normal   Assigned To

Created on 2009-09-04.02:32:11 by stephen, last changed 2009-09-06.03:14:05 by FKtPp.

Messages
msg1835 [hidden] ([hidden]) Date: 2009-09-06.03:14:05
  Message-ID: <1252206845.68.0.413834290885.issue565@xemacs.org>
On δΊ”, 2009-09-04 at 09:51 +0900, Stephen J. Turnbull wrote:
> If you get a hang (which means infloop), at this point put a break on
> xcb_wait_for_event.  Do 'continue' in gdb (you may need to do it twice
> to get XEmacs to run), and see if you get back to xcb_wait_for_event.
> 
> If you do, then you need to single-step and see if control ever
> returns to XEmacs.  My experience as reported in the bug above was
> that it does not; it infloops inside of Xt.
> 

Yes, confirmed, it never return to xemacs :(

> If so, that is an Xt bug.  AFAICT, XEmacs never makes a blocking call
> to Xt without guarding it with XtAppPending, to make sure there is an
> event to process and therefore Xt will not block.
> 
>  > #3  0x00007f93ccc85688 in ?? () from /usr/lib/libX11.so.6
>  > #4  0x00007f93ccc85a3d in ?? () from /usr/lib/libX11.so.6
>  > #5  0x00007f93ccc862f9 in _XReadEvents () from /usr/lib/libX11.so.6
>  > #6  0x00007f93ccc64bd4 in XIfEvent () from /usr/lib/libX11.so.6
>  > #7  0x00007f93cccb0920 in ?? () from /usr/lib/libX11.so.6
>  > #8  0x00007f93cccafb69 in ?? () from /usr/lib/libX11.so.6
>  > #9  0x00007f93cccaff13 in _XimRead () from /usr/lib/libX11.so.6
>  > #10 0x00007f93ccc9ddf3 in ?? () from /usr/lib/libX11.so.6
>  > #11 0x00007f93ccc8b53a in XSetICValues () from /usr/lib/libX11.so.6
>  > #12 0x0000000000507f38 in XIM_SetSpotLocation (f=0x32c76f0, x=461,
y=97)
>  > at input-method-xlib.c:463
> 
> Are you actually using XIM? 

Yes, I have input some chinese.

>  If not, you can possibly get relief by
> using --with-xim=no, although I would prefer that you try to track
> down the bug (even though I believe it isn't ours, this is a nasty
> one!)
> 
> N.B. ISTM I've seen XIM in backtraces where it has no business, ie,
> --with-xim=no builds.  That suggests that Xlib or Xt is calling into
> XIM even though XEmacs doesn't want it.

Ah. --with-xim=no seems fixed the issue, I've tried hold n or p for a
very long time in some directory with lot of file in it but can't
reproduce the infloop any more.

Thanks,
FKtPp
msg1833 [hidden] ([hidden]) Date: 2009-09-04.02:32:11
  Message-ID: <1252031532.15.0.851436673494.issue565@xemacs.org>
It's me FKtPp ;) writes: 
 
 > I've reproduce this several times on my ubuntu machine, but don't know 
 > what is wrong... I've also run xemacs in gdb, but it seemed that xemacs 
 > didn't hang. Only the GUI is not response anymore. 
 
It's an Xt (in this case, moved to xcb it seems) bug.  See 
 
https://trac.macports.org/ticket/18491 
 
Despite the status of that ticket, it is NOT fixed.  They patched a 
couple of cases, but there are still many ways for _XtWaitForSomething 
to infloop.  And I would be totally unsurprised if the fix hasn't been 
applied to xcb_wait_for_event, which I bet is the xcb equivalent to 
_XtWaitForSomething. 
 
This hang seems to happen most from XIM calls, I'm not sure why. 
 
I suspect it has to do with changes in the kernel, too, as I've very 
recently started to see a lot of them on my Gentoo box.  poll() and 
select() have very subtle semantics, and many programs do not handle 
them very well. 
 
 > I tried to press C-c in gdb and get a backtrace(don't know it is useful 
 > or not) 
 >  
 > #0  0x00007f93cbb596f3 in select () from /lib/libc.so.6 
 > #1  0x00007f93cad991ae in ?? () from /usr/lib/libxcb.so.1 
 > #2  0x00007f93cad9a91a in xcb_wait_for_event () 
 > from /usr/lib/libxcb.so.1 
 
If you get a hang (which means infloop), at this point put a break on 
xcb_wait_for_event.  Do 'continue' in gdb (you may need to do it twice 
to get XEmacs to run), and see if you get back to xcb_wait_for_event.
If you do, then you need to single-step and see if control ever 
returns to XEmacs.  My experience as reported in the bug above was 
that it does not; it infloops inside of Xt. 
 
If so, that is an Xt bug.  AFAICT, XEmacs never makes a blocking call 
to Xt without guarding it with XtAppPending, to make sure there is an 
event to process and therefore Xt will not block. 
 
 > #3  0x00007f93ccc85688 in ?? () from /usr/lib/libX11.so.6 
 > #4  0x00007f93ccc85a3d in ?? () from /usr/lib/libX11.so.6 
 > #5  0x00007f93ccc862f9 in _XReadEvents () from /usr/lib/libX11.so.6 
 > #6  0x00007f93ccc64bd4 in XIfEvent () from /usr/lib/libX11.so.6 
 > #7  0x00007f93cccb0920 in ?? () from /usr/lib/libX11.so.6 
 > #8  0x00007f93cccafb69 in ?? () from /usr/lib/libX11.so.6 
 > #9  0x00007f93cccaff13 in _XimRead () from /usr/lib/libX11.so.6 
 > #10 0x00007f93ccc9ddf3 in ?? () from /usr/lib/libX11.so.6 
 > #11 0x00007f93ccc8b53a in XSetICValues () from /usr/lib/libX11.so.6 
 > #12 0x0000000000507f38 in XIM_SetSpotLocation (f=0x32c76f0, x=461, y=97) 
 > at input-method-xlib.c:463 
 
Are you actually using XIM?  If not, you can possibly get relief by 
using --with-xim=no, although I would prefer that you try to track 
down the bug (even though I believe it isn't ours, this is a nasty 
one!) 
 
N.B. ISTM I've seen XIM in backtraces where it has no business, ie, 
--with-xim=no builds.  That suggests that Xlib or Xt is calling into 
XIM even though XEmacs doesn't want it.
History
Date User Action Args
2009-09-06 03:14:05FKtPpsetmessages: + msg1835
2009-09-04 02:32:11stephencreate