Gary Beckmann <gbeckmann <at> RADIONICS.com> writes:
Periodically, xemacs will "hang" (stop taking input, not refresh
screen). When killed, the back traces look like:
Lisp backtrace follows:
own-selection-internal(CLIPBOARD "\n" nil nil)
# bind (zmacs-region-stays data-type how-to-add type data)
own-selection("\n" CLIPBOARD)
# bind (push string)
own-clipboard("\n" t)
# bind (replace string)
kill-new("\n")
# bind (undo-high-threshold tail verbose end start)
kill-region(558 559)
# bind (entire-line arg)
kill-line-1(nil nil)
# bind (arg)
kill-line(nil)
# bind (command-debug-status)
call-interactively(kill-line)
# (condition-case ... . error)
# (catch top-level ...)
I experience this with XEmacs 21.4.21 on FreeBSD 8.0-RELEASE under
X.Org X Server 1.7.5.
As the Lisp backtrace shows, it occurs in association with killing a line.
It occurs infrequently, but once the problem starts, killing XEmacs and
restarting only helps up until the point where you type ^K again.
When XEmacs hangs, it does so in a CPU-intensive interaction with the
X server, not a "passive" hang.
What *does* help is to restart the X server. There seems to be some
tight loop in the interaction between XEmacs and the X server that
is triggered by some state the X server (clipboard?). It has not been
clear to me whether it is XEmacs or the X server that is the "guilty" party.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta