Subject: bug#16521: closed (Re: bug#17168: 24.3.50; Segfault at mark_object)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 07 Apr 2014 18:41:10 +0000

Your bug report

#17168: 24.3.50; Same GC crash

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
17168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17168
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#17168: 24.3.50; Segfault at mark_object
From: Stefan Monnier <[email-masked]>
To: Daniel Colascione <[email-masked]>
Cc: Dmitry Antipov <[email-masked]>, [email-masked]
Date: Mon, 07 Apr 2014 12:28:20 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

> Anyway, I'd like to get a fix into emacs-24 soon so we can make sure
> we've fixed the GC bug.

I installed a fix into emacs-24, which lets all symbols be uninterned.

> Are you vetoing the general approach used in this patch?

No: I think disallowing unintern is a good idea, but not for emacs-24.

Indeed, as it turns out, the only non-pure objects referenced from pure
space are symbols and distinguishing uninterned from interned reduces
the number of such "pinned" objects from about 10K to about 250.

Rather than scan all symbols to find the pinned ones, the code
I installed into emacs-24 keeps a pointer to the first symbol_block
that contains a pinned symbol.  This way we only scan about 15K symbols
at the beginning of every GC cycle to mark those 10K pinned symbols.
Compared to keeping a vector of 10K object, this seems like
a good tradeoff.

For trunk, we could disallow uninterning pinned symbols, at which point
it's worth the trouble to build a vector of those 250 remaining
pinned symbols.

        Stefan

Subject: 24.3.50; Same GC crash
From: Richard Stallman <[email-masked]>
To: [email-masked]
Date: Wed, 22 Jan 2014 10:31:41 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

The same sort of GC crash related to the symbol clear-temporary-overlay-map
has happened again.  The symbol name is different but the crash
looked the same.

In GNU Emacs 24.3.50.19 (mips64el-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2014-01-20 on chiefs-gnewsense
Repository revision: 116080 [email-masked]
System Description:	gNewSense GNU/Linux 3.0 (parkes)

Configured using:
 `configure 'CFLAGS=-g -O0''

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: RMAIL

Minor modes in effect:
  shell-dirtrack-mode: t
  gpm-mouse-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent messages:
Wrote /home/rms/foo.html
Mark set [2 times]
Auto-saving...done
Mark set
Beginning of buffer
Mark set
Auto-saving...done
Sending...
Wrote /home/rms/outgoing/out-33
Sending...done

Load-path shadows:
/home/rms/emacs-bzr/trunk/lisp/leim/quail/lao hides /home/rms/emacs-bzr/trunk/lisp/language/lao
/home/rms/emacs-bzr/trunk/lisp/leim/quail/georgian hides /home/rms/emacs-bzr/trunk/lisp/language/georgian
/home/rms/emacs-bzr/trunk/lisp/leim/quail/thai hides /home/rms/emacs-bzr/trunk/lisp/language/thai
/home/rms/emacs-bzr/trunk/lisp/leim/quail/ethiopic hides /home/rms/emacs-bzr/trunk/lisp/language/ethiopic
/home/rms/emacs-bzr/trunk/lisp/leim/quail/japanese hides /home/rms/emacs-bzr/trunk/lisp/language/japanese
/home/rms/emacs-bzr/trunk/lisp/leim/quail/cyrillic hides /home/rms/emacs-bzr/trunk/lisp/language/cyrillic
/home/rms/emacs-bzr/trunk/lisp/leim/quail/indian hides /home/rms/emacs-bzr/trunk/lisp/language/indian
/home/rms/emacs-bzr/trunk/lisp/leim/quail/hebrew hides /home/rms/emacs-bzr/trunk/lisp/language/hebrew
/home/rms/emacs-bzr/trunk/lisp/leim/quail/greek hides /home/rms/emacs-bzr/trunk/lisp/language/greek
/home/rms/emacs-bzr/trunk/lisp/leim/quail/czech hides /home/rms/emacs-bzr/trunk/lisp/language/czech
/home/rms/emacs-bzr/trunk/lisp/leim/quail/slovak hides /home/rms/emacs-bzr/trunk/lisp/language/slovak
/home/rms/emacs-bzr/trunk/lisp/leim/quail/tibetan hides /home/rms/emacs-bzr/trunk/lisp/language/tibetan

Features:
(shadow emacsbug ispell mule-util find-func debug dired-aux jka-compr
epa-mail epa derived epg epg-config dabbrev rmailsum quail help-mode
rmailout shell pcomplete grep mailalias qp warnings dframe cl-macs gv
cl-loaddefs cl-lib byte-opt compile comint ansi-color ring bytecomp
byte-compile cconv misearch multi-isearch vc-bzr rmailmm message
sendmail format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies
mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 dired
t-mouse package rmailedit rmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils time-date paren cus-start cus-load advice
help-fns tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind gfilenotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.