Fatal error (11). Emacs/ Linux hosed my very long document.

[Mike Cox]

I recently switched to xemacs as my default word processor so I could
do formatting in TEX for a very long document.  Most recently I've
been using Microsoft Word, the latest version.  I switched because I
thought that emacs had perfect stability and no crashes.  My
perception was formed due to the constant FSF/GPL/Linux advocacy
promoted on slashdot and all the comp newsgroups.

I was also inspired by Paul Graham's claims that LISP will not core
dump and you can debug and get back to work.

So with this background, I decided that my comprehensive review of
Linux, and GNU programs would be written using all open source tools
and operating systems.  This review was to be submitted to several
news sites including slashdot and OSNEWS.

Much to my dismay, as I was working on my very long review (about 100
pages typed), xemacs core dumped on me.  I was unable to recover
anything.  I didn't save my document because I never expected emacs to
core dump.  The worst I thought would happen would be some LISP error.
Hopefully someone can debug emacs and fix this dangerous bug.  Until
then, I'm probably going to go back to Microsoft Word 2003.  THe
following is my core dump file:

linux:~ # xemacs
 
Fatal error (11).
 
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
 
Your version of XEmacs was distributed with a PROBLEMS file that  may
describe
your crash, and with luck a workaround.  Please check it first, but do
report
the crash anyway.  Please report this bug by invoking M-x
report-emacs-bug,
or by selecting `Send Bug Report' from the Help menu.  If necessary,
send
ordinary email to `crashes@xemacs.org'.  *MAKE SURE* to include the
XEmacs
configuration from M-x describe-installation, or equivalently the file
Installation in the top of the build tree.
 
*Please* try *hard* to obtain a C stack backtrace; without it, we are
unlikely
to be able to analyze the problem.  Locate the core file produced as a
result
of this crash (often called `core' or `core.<process-id>', and located
in
the directory in which you started XEmacs or your home directory), and
type
 
  gdb /usr/X11R6/bin/xemacs core
 
then type `where' at the debugger prompt.  No GDB on your system?  You
may
have DBX, or XDB, or SDB.  (Ask your system administrator if you need
help.)
If no core file was produced, enable them (often with `ulimit -c
unlimited'
in case of future recurrance of the crash.
 
Lisp backtrace follows:
 
  redisplay-echo-area()
  # bind (inhibit-read-only zmacs-region-stays stdout-p frame message)
  raw-append-message("space = select, d = keywords, e = edit, v =
view, q = quit, ? = help" #<x-frame "emacs" 0x1c93> nil)
  # bind (stdout-p frame message label)
  append-message(message "space = select, d = keywords, e = edit, v =
view, q =
quit, ? = help" nil nil)
  # bind (stdout-p frame message label)
  display-message(message "space = select, d = keywords, e = edit, v =
view, q = quit, ? = help")
  # bind (str args fmt)
  message("%s" "space = select, d = keywords, e = edit, v = view, q =
quit, ? =
help")
  finder-summary()
  # bind (id key)
  finder-list-matches("news")
  # bind (key)
  #<compiled-function nil "...(19)" [finder-file-regexp key
finder-current-item
string-match finder-commentary finder-list-matches] 3 nil nil>()
  call-interactively(finder-select)
  # (condition-case ... . error)
  # (catch top-level ...)
Segmentation fault