[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

emacs sometimes crashes

From: Reinhard Kotucha
Subject: emacs sometimes crashes
Date: Tue, 17 Aug 2004 01:54:42 +0200

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the address@hidden mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.3.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2004-01-14 on zarniwoop
configured using `configure  --with-x-toolkit=athena --with-xpm --with-jpeg 
--with-tiff --with-gif --with-png --prefix=/usr/local/dtp'
Important settings:
  value of $LC_ALL: en_US.ISO-8859-1
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: ISO-8859-1
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Hard to say, it always happened when I was reading mails in vm.  But
this is what I do most of the time.  It does not happen very often,
maybe 3 or 4 times a year.  Emacs is running all the time,  from one
crash to the next (or to the next power failure).

A few months ago I removed the line "ulimit -c 0" from /etc/profile,
so I have a core file now.

I never used gdb before, so if you need more information please tell
me the commands I have to type in gdb.

It seems that the garbage collector is the culprit:

$ gdb -c core
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-slackware-linux".
Core was generated by `emacs -f vm'.
Program terminated with signal 6, Aborted.
#0  0x402ad4c1 in ?? ()
(gdb) file /usr/local/dtp/bin/emacs
Reading symbols from /usr/local/dtp/bin/emacs...done.
(gdb) backtrace 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 "\\=8e7=8c6\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

(gdb) frame 16
#16 0x804f338 in safe_bcopy (from=0x9c94394 "\\=8e7=8c6\t", to=0x9cb6c80 "", 
    size=164030292) at dispnew.c:486
486                   bcopy (endf, endt, to - from);
(gdb) info frame 
Stack level 16, frame at 0xbfffda58:
 eip = 0x804f338 in safe_bcopy (dispnew.c:486); saved eip 0x810abc6
 called by frame at 0xbfffda88, caller of frame at 0xbfffda38
 source language c.
 Arglist at 0xbfffda58, args: from=0x9c94394 "\\=8e7=8c6\t", to=0x9cb6c80 "", 
 Locals at 0xbfffda58, Previous frame's sp is 0x0
 Saved registers:
  ebx at 0xbfffda4c, ebp at 0xbfffda58, esi at 0xbfffda50, edi at 0xbfffda54,
  eip at 0xbfffda5c
(gdb) info locals 
endf = 0x138e01fc <Address 0x138e01fc out of bounds>
endt = 0x13902ae8 <Address 0x13902ae8 out of bounds>
size = -1073754788

(gdb) frame 17
#17 0x810abc6 in compact_small_strings () at alloc.c:1635
1635                      safe_bcopy ((char *) from, (char *) to, nbytes);
(gdb) info frame 
Stack level 17, frame at 0xbfffda88:
 eip = 0x810abc6 in compact_small_strings (alloc.c:1635); saved eip 0x810aaeb
 called by frame at 0xbfffdabc, caller of frame at 0xbfffda58
 source language c.
 Arglist at 0xbfffda88, args: 
 Locals at 0xbfffda88, Previous frame's sp is 0x0
 Saved registers:
  ebx at 0xbfffda6c, ebp at 0xbfffda88, esi at 0xbfffda70, edi at 0xbfffda74,
  eip at 0xbfffda8c
(gdb) info locals 
nbytes = 0
b = (struct sblock *) 0x9c92c08
tb = (struct sblock *) 0x9cb6c78
next = (struct sblock *) 0x139253d4
from = (struct sdata *) 0x6
to = (struct sdata *) 0x9cb6c80
end = (struct sdata *) 0x9c94bf0
tb_end = (struct sdata *) 0x9cb8c74
to_end = (struct sdata *) 0x139253d4
from_end = (struct sdata *) 0x13902ae8

If you need more information, please let me know.

BTW., emacs obviously writes an auto-backup after it gets SIGSEGV.
But can I rely on it when SIGSEGV was caused by the garbage collector?


Reinhard Kotucha                                      Phone: +49-511-4592165
Marschnerstr. 25
D-30167 Hannover                              mailto:address@hidden
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]