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