Subject: bug#15583: 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:04 +0000

Your bug report

#17168: 24.3.50; GC crashes

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; GC crashes
From: Richard Stallman <[email-masked]>
To: [email-masked]
Date: Thu, 10 Oct 2013 12:28:19 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

Over the past few weeks, since updating, I have had several crashes in
mark_object.  The crashes started when I updated somewhere between Sep
17 and Sep 22.  (I don't know how to tell more precisely when that
was.)

I did another update a week ago, hoping the problem would go away,
but yesterday I got another crash of the same sort.

My previous update had been around Aug 18; the crashes did not
happen in that version.

mark_object is reached about 3 levels down from mark_memory.
Thus, I could not easily tell much about what data structure it was.
If it is useful, I will try harder to get more info.

In GNU Emacs 24.3.50.11 (mips64el-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2013-10-03 on chiefs-gnewsense
Bzr revision: 114502 [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
  default enable-multibyte-characters: t

Major mode: RMAIL

Minor modes in effect:
  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 input:
m e , SPC o r SPC s o m e SPC o t h e r SPC v 4 r DEL 
DEL e r s i o n SPC o f SPC i t . RET ESC ; C-c C-c 
n d x d u d d x n d u x C-u C-u C-n C-u C-n C-n C-@ 
C-n C-n C-n C-n r ESC , C-p C-p C-p C-p C-u C-n C-n 
C-o C-o C o u l d SPC s o m e o n e SPC t r y SPC t 
h a t ? C-c C-c ESC v C-x b o u t g TAB RET g C-p C-p 
C-p C-p C-o C-x o C-x b R TAB RET 1 r C-x o C-u C-p 
C-@ C-n ESC , C-p ESC f ESC f ESC f ESC f C-k RET RET 
T h e SPC w o r d SPC i s SPC " p i q u e d " . SPC 
SPC ( I t SPC c o m e ESC DEL i s SPC a SPC r c DEL 
e c e n t SPC b o r r o w i n g SPC f r o m SPC F r 
n e c h DEL DEL DEL DEL e n c . DEL h . ) C-n C-c C-c 
d d u d d d u x o g i t h TAB ESC DEL x m a i l / g 
i t h TAB RET d d ESC x r e s e n d SPC m a i l SPC 
a d d DEL DEL DEL SPC a d d r ESC DEL ESC DEL r e p 
o r t SPC e m a TAB RET

Recent messages:
Wrote /home/rms/outgoing/out-59
Sending...done
Mark activated
Mark set
Auto-saving...done
Sending...
Wrote /home/rms/outgoing/out-60
Sending...done
Expunging deleted messages...done
Added to /home/rms/xmail/github.xmail

Load-path shadows:
/home/rms/emacs-bzr/trunk/lisp/net/shr-color hides /home/rms/emacs-bzr/trunk/lisp/gnus/shr-color
/home/rms/emacs-bzr/trunk/lisp/net/shr hides /home/rms/emacs-bzr/trunk/lisp/gnus/shr

Features:
(shadow emacsbug rmailout mailalias qp quail help-mode misearch
multi-isearch 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 finder-inf package rmailedit rmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date
paren cus-start cus-load advice help-fns tooltip 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.