bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#18457: GC crashes followed by update_syntax_table/interval_of crash


From: Dmitry Antipov
Subject: bug#18457: GC crashes followed by update_syntax_table/interval_of crash
Date: Fri, 12 Sep 2014 12:10:45 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

On 09/12/2014 07:07 AM, David Reitter wrote:

There is a source of a common “args out of range” crash in
update_syntax_table/interval_of, secondary to GC exceptions.

If Emacs is crashed when GC is in progress (usually in mark_object), most
probably an internal data structures are seriously broken and anything can
happen.  As for the two stack traces below, the final reason for emacs_abort
was a call to Fsignal with non-zero gc_in_progress.

Except "regular" GC crashes, there are few less likely reasons, including:

1) Internal data structures are correct but large so that recursive traversal
   runs out of C stack space.  We made some efforts to minimize stack usage, see
   http://lists.gnu.org/archive/html/emacs-diffs/2014-06/msg00116.html and
   http://lists.gnu.org/archive/html/emacs-diffs/2014-06/msg00124.html,
   so I believe that such a cases should be very rare, unless an OS has the
   relatively small (say, < 1M) stack size limit.  (This code is not planned for
   24.4 but may be backported from main development trunk).

2) Compiler optimizations that confuses stack marking code, see:
   http://lists.gnu.org/archive/html/emacs-diffs/2014-08/msg00024.html
   Currently we have no regular method to detect these errors.
   Also see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16986; note that
   it was observed on OSX, and there is an assumption that clang is more
   aggressive in such an optimizations rather than gcc.

https://bugzilla.redhat.com/show_bug.cgi?id=991073

If a bug report is not reduced to a clean and simple recipe starting from 
'emacs -Q',
it's unlikely to be seriously attended (especially if it doesn't bother the 
most of
active developers).  C core of Emacs is developed and maintained by a 
relatively small
group, and I'm curious whether someone would play with ESS and R just to 
reproduce
bug in 24.3 released 1.5 years ago.

As for the Fedora community, why not using pre-releases from
ftp://alpha.gnu.org/gnu/emacs/pretest to build rawhide packages?  This can be 
very
helpful because we always need more testers, and a lot of 24.3 bugs are really 
fixed
in 24.3.9x.

Dmitry






reply via email to

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