[Bug: 21.4.18] Crash in 'M-x shell' after using 100% CPU for 2 hours
Christian Brechbhler writes:
After running smootly for many days, my xemacs started using 100%
CPU.
What XEmacs applications did you use over this period? The more
complete the list the better.
It was still responsive but slow. After it had consumed about 2
hours
of CPU time, I started shell to investigate. It hung in "fontifying
..." a long time, I typed C-g C-g C-g, then the session crashed.
XEmacs should never crash; any crash indicates an XEmacs bug, unless
there's a system resource issue (typically out of memory).
abort-progress-feedback(font-lock "Fontifying *shell*...
aborted." nil)
This seems to be the cause of the crash as such. The widget used is
known to be buggy. You can work around this problem by using
(setq progress-feedback-use-echo-area t)
in your init file. This tends to speed up fontification a bit, but
AFAIK this bug is not related to 100% CPU usage.
This particular bug has not been solved yet, but others have. You may
wish to update your XEmacs to 21.4.20.
warning: core file may not match specified executable file.
Is there any reason to believe this warning? (Often there is not; I'm
not sure why it gets generated incorrectly, but the wording suggests
that it's quite common.)
Loaded symbols for /usr/lib/libXfixes.so.3
#0 0x00002aaaac1bd729 in kill ()
from /lib/libc.so.6
(gdb) where
#0 0x00002aaaac1bd729 in kill () from /lib/libc.so.6
#1 0x0000000000479f7e in fatal_error_signal ()
#2 0x00002aaaac1bd1b0 in killpg () from /lib/libc.so.6
#3 0x0000000000000000 in ?? ()
The stack is totally trashed; not much we can do with this.
Note that most distros strip the binaries of symbol table information.
This makes backtraces far less useful; it is often difficult to even
identify the function with the problem due to inlining and static
declarations. Many distros provide a -debug package which contains an
unstripped XEmacs binary, or a symbol table in a separate file. The
separate file can be loaded into gdb with
(gdb) symbol-file $FILE
However, you also have an enormous number of Lisp shadows. This is
bad because Emacs Lisp has no notion of namespaces, and no real notion
of "package" outside of a library file (.el). Thus you can get code
mixed from different versions very easily.
In case it matters, I had also used gnuserv, attached from outside
with a gnuclient (which this morning became unresponsive), killed and
restarted gnuserv.
Thank you for that information.
By the way, this is my 3rd attempt to run M-x report-emacs-bug. It
failed the first time with "Wrong type argument: keymapp, nil", the
second time with "Buffer is read-only: #<buffer
\"xemacs-crash\">".
This seem to be a possible symptom of Lisp library mix-n-match due to
the shadows.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta