XEmacs GUI hang when press n or p for a while in dired-mode

It's me FKtPp ;) writes: 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. 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. 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. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta