GNU bug report logs - #18457
GC crashes followed by update_syntax_table/interval_of crash

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 18457 <at> debbugs.gnu.org
Subject: bug#18457: GC crashes followed by update_syntax_table/interval_of crash
Date: Fri, 12 Sep 2014 12:10:45 +0400

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.