[Bug: 21.4.18] Crash in 'M-x shell' after using 100% CPU for 2 hours

[Stephen J. Turnbull]

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.