From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.user/4105 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.gnus.user Subject: Re: Fatal error (11). Emacs/ Linux hosed my very long document. Date: Fri, 17 Sep 2004 08:02:03 +0200 Organization: Organization?!? Message-ID: References: <3d6111f1.0409161437.30ef8b7d@posting.google.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1138670100 21833 80.91.229.2 (31 Jan 2006 01:15:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2006 01:15:00 +0000 (UTC) Original-X-From: nobody Tue Jan 17 17:33:14 2006 Original-Path: quimby.gnus.org!newsfeed.gazeta.pl!fu-berlin.de!uni-berlin.de!not-for-mail Original-Newsgroups: comp.os.linux.advocacy,comp.editors,comp.emacs.xemacs,gnu.emacs.gnus Original-X-Trace: news.uni-berlin.de NkXCG50Wb9RkLDZc+INH/wPrrPzfA+qyIUttVMbDtuZxJgXs/S X-Face: 2FEFf>]>q>2iw=B6,xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN;i";/yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:KprETZA/zXpWpaeEFkOCj2+WAB4= Original-Xref: bridgekeeper.physik.uni-ulm.de gnus-emacs-gnus:4246 Original-Lines: 92 X-Gnus-Article-Number: 4246 Tue Jan 17 17:33:14 2006 Xref: news.gmane.org gmane.emacs.gnus.user:4105 Archived-At: 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" # 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) > # 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