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.
|