emacs dumps core

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

Re: emacs dumps core

[Håkon Alstadheim]

Reinhard Kotucha <reinhard@zarniwoop.ms25.local> writes:

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

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

Mine crashes usually while running gnus, but that's maybe because
that's what I use emacs for most. I have another emacs running with an
inferior lisp process, and that one stays up indefinitely.

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

Mine is usually somwhere witing (several) invocations of re_seach.

>
> Is it possible that the garbage collector has problems with
> libsafe.so.1.3?

I'm not using libsafe


$ uname -a
Linux alstadheim 2.6.5-7.95-athlon #2 Mon Jul 5 18:26:41 CEST 2004 i686 athlon i386 GNU/Linux

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.3/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.3 (SuSE Linux)

$ ld -v
GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux)

ldd `which emacs`
        linux-gate.so.1 =>  (0xffffe000)
        libXaw3d.so.7 => /usr/X11R6/lib/libXaw3d.so.7 (0x4003f000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40097000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x400ad000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40100000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4010a000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40122000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40131000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40182000)
        libpng.so.3 => /usr/lib/libpng.so.3 (0x401a1000)
        libm.so.6 => /lib/tls/libm.so.6 (0x401ce000)
        libungif.so.4 => /usr/lib/libungif.so.4 (0x401f0000)
        libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x401f9000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40208000)
        libncurses.so.5 => /lib/libncurses.so.5 (0x40304000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40349000)
        libz.so.1 => /lib/libz.so.1 (0x4045e000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libdl.so.2 => /lib/libdl.so.2 (0x40470000)

(gdb) backtrace
#0  0x08127881 in re_search ()
#1  0x08127995 in re_search ()
#2  0x0813366e in re_search ()
#3  0x081336e4 in re_search ()
#4  0x080656f6 in ?? ()
#5  0x00000001 in ?? ()
#6  0x0000000f in ?? ()
#7  0x00000001 in ?? ()
#8  0x484eca00 in ?? ()
#9  0x48497160 in ?? ()
#10 0x484eca00 in ?? ()
#11 0xbfffca3c in ?? ()
#12 0x08063cfd in ?? ()
#13 0xbfffca58 in ?? ()
#14 0x1829d42c in ?? ()
#15 0x00000000 in ?? ()
#16 0x00000000 in ?? ()
#17 0x404703a0 in ?? ()
#18 0x00000001 in ?? ()
#19 0x00000000 in ?? ()
#20 0x0000005d in ?? ()
#21 0x00000000 in ?? ()
#22 0x00000001 in ?? ()
---Type <return> to continue, or q <return> to quit---
#23 0x080656b0 in ?? ()
#24 0x00006437 in ?? ()
#25 0x0000000b in ?? ()
#26 0x1829d42c in ?? ()
#27 0xbfffca5c in ?? ()
#28 0x08063f98 in ?? ()
#29 0xbfffca58 in ?? ()
#30 0x1829d42c in ?? ()
#31 0x00000000 in ?? ()
#32 0x00000000 in ?? ()
#33 0xbfffcae4 in ?? ()
#34 0x40016c18 in ?? ()
#35 0xbfffca7c in ?? ()
#36 0x08063fcc in ?? ()
#37 0x6c616240 in ?? ()
#38 0x2e727564 in ?? ()
#39 0x696f6877 in ?? ()
#40 0x40351048 in ?? () from /lib/tls/libc.so.6
#41 0x401f9788 in ?? ()
#42 0x00006437 in ?? ()
#43 0xbfffcb0c in ?? ()
#44 0x08107b89 in abort ()
Previous frame inner to this frame (corrupt stack?)
(gdb)
-- 
Håkon Alstadheim, hjemmepappa.