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

[David Kastrup <dak@gnu.org>]

mikecoxlinux@yahoo.com (Mike Cox) writes:

> 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

to troll on a number of Usenet groups, as witnessed by the selection
of groups you post to, and by your posting history.

> 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).

So you managed to get an XEmacs executable that would dump core right
at the start, because of faulty RAM, because of bad libraries, because
of bad compilation options (see the PROBLEMS file).  It is an
impressive feat to write a 100 page document with an editor that dumps
core before you can type a single character or load a file.

> Your files have been auto-saved.
> Use `M-x recover-session' to recover them.

That's more or less all there is to it.  The auto-save files are named
#filename# or similar, so in case that you have an XEmacs that dumps
core before you can recover the session, you can just work from there,
with the naked file.

> 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.

[...]

> 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

This Lisp backtrace does not point to any editing actions, anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum