emacs dumps core

[Reinhard Kotucha]

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 <auto_save_1>, 
    handlers=405204148, hfun=0x80f48ec <auto_save_error>) 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.
----------------------------------------------------------------------------