From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Reinhard Kotucha Newsgroups: gmane.emacs.help Subject: emacs dumps core Date: 05 Aug 2004 23:13:56 +0200 Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1091740635 27754 80.91.224.253 (5 Aug 2004 21:17:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 5 Aug 2004 21:17:15 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Aug 05 23:17:04 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bspbj-0006EQ-00 for ; Thu, 05 Aug 2004 23:17:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BspfH-0003fl-6v for geh-help-gnu-emacs@m.gmane.org; Thu, 05 Aug 2004 17:20:43 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!newsmi-us.news.garr.it!newsmi-eu.news.garr.it!NewsITBone-GARR!fu-berlin.de!uni-berlin.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 114 Original-X-Trace: news.uni-berlin.de tGz9W9cVSGtyzFgIZsBGXAN4ZFa+UAW+Cml/H0tiunGzvkUXUd User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Original-Xref: shelby.stanford.edu gnu.emacs.help:124667 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:20001 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:20001 Hi, from time to time emacs 21.3 crashes and dumps a core file. I had the same problem with 21.2 and 21.1 as well. All crashes occurred when I was reading mail in vm. Usually, emacs runs stable for weeks or months. This time I started emacs on Monday when I came back from holidays and it crashed today. Since I was away for a month, my INBOX file is quite large (37 MB). I suppose that the problem occurs during garbage collection in large buffers. Sometimes vm becomes very slow. Then I have to quit vm and start it again. Looks like a problem with the garbage collector as well. I loaded the core file into gdb. See the output below. I never used gdb before. If it can provide more useful information please tell me what I have to do. Emacs got signal 11 (segmetation fault) in #14. In #20 it called Fgarbage_collect (). Is it possible that the garbage collector has problems with libsafe.so.1.3? http://www.research.avayalabs.com/project/libsafe/doc/libsafe.8.html If you need more information, please let me know. Regards, Reinhard ----------------------------------------------------------------------- $ uname -a Linux zarniwoop 2.2.16 #9 SMP Sun Jan 5 23:13:52 CET 2003 i686 unknown $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) $ ld -v GNU ld version 2.10.1 (with BFD 2.10.1) $ ldd /usr/local/bin/emacs /lib/libsafe.so.1.3 => /lib/libsafe.so.1.3 (0x40015000) libXaw3d.so.6 => /usr/X11R6/lib/libXaw3d.so.6 (0x4001a000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4006b000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4007d000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x400c6000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x400cf000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400e4000) libtiff.so.3 => /usr/local/lib/libtiff.so.3 (0x400f8000) libjpeg.so.62 => /usr/local/lib/libjpeg.so.62 (0x40138000) libpng.so.3 => /usr/local/lib/libpng.so.3 (0x40157000) libm.so.6 => /lib/libm.so.6 (0x4018c000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x401a8000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401b5000) libncurses.so.5 => /lib/libncurses.so.5 (0x40253000) libc.so.6 => /lib/libc.so.6 (0x4028f000) libdl.so.2 => /lib/libdl.so.2 (0x40379000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) (gdb) bt 25 #0 0x402ad4c1 in ?? () #1 0x402ad3d8 in ?? () #2 0x811bea8 in Fsignal (error_symbol=405300492, data=1506441636) at eval.c:1387 #3 0x810e567 in wrong_type_argument (predicate=405300900, value=405373412) at data.c:119 #4 0x8122ed2 in Fplist_get (plist=-668253348, prop=405373412) at fns.c:1884 #5 0x8122f15 in Fget (symbol=405328532, propname=405373412) at fns.c:1896 #6 0x808abc8 in Fcoding_system_p (obj=405328532) at coding.c:6175 #7 0x808acce in Fcheck_coding_system (coding_system=405328532) at coding.c:6221 #8 0x808b821 in code_convert_string_norecord (string=962768540, coding_system=405328532, encodep=1) at coding.c:6650 #9 0x80f3cdd in Fwrite_region (start=1, end=37819064, filename=962768540, append=405204100, visit=405300348, lockname=962768540, mustbenew=405204100) at fileio.c:4787 #10 0x80f4a07 in auto_save_1 () at fileio.c:5444 #11 0x811bc50 in internal_condition_case (bfun=0x80f4994 , handlers=405204148, hfun=0x80f48ec ) at eval.c:1267 #12 0x80f4e13 in Fdo_auto_save (no_message=405204148, current_only=405204100) at fileio.c:5634 #13 0x80cdaca in shut_down_emacs (sig=11, no_x=0, stuff=405204100) at emacs.c:1883 #14 0x80cc46b in fatal_error_signal (sig=11) at emacs.c:341 #15 0x402ad3d8 in ?? () #16 0x804f338 in safe_bcopy (from=0x9c94394 "\\çÆ\t", to=0x9cb6c80 "", size=164030292) at dispnew.c:486 #17 0x810abc6 in compact_small_strings () at alloc.c:1635 #18 0x810aaeb in sweep_strings () at alloc.c:1542 #19 0x810da5b in gc_sweep () at alloc.c:4928 #20 0x810ce95 in Fgarbage_collect () at alloc.c:4194 #21 0x8142239 in Fbyte_code (bytestr=943825052, vector=1212900656, maxdepth=7) at bytecode.c:759 #22 0x811d9a8 in funcall_lambda (fun=1212282648, nargs=3, arg_vector=0xbfffdc78) at eval.c:2851 #23 0x811d5d9 in Ffuncall (nargs=4, args=0xbfffdc74) at eval.c:2716 #24 0x814214d in Fbyte_code (bytestr=943857308, vector=1212271296, maxdepth=6) at bytecode.c:716 -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------