GNU bug report logs - #17168
24.3.50; Segfault at mark_object

Previous Next

Full log

View this message in rfc822 format

From: Daniel Colascione <dancol <at> dancol.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 17168 <at> debbugs.gnu.org
Subject: bug#17168: 24.3.50; Segfault at mark_object
Date: Sun, 06 Apr 2014 14:37:44 -0700

[Message part 1 (text/plain, inline)]

On 04/06/2014 02:08 PM, Stefan Monnier wrote:
>> Sure.  But why would you ever want to unintern a symbol that pure storage
>> references?
> 
> That's a good question.  But it cuts both ways: if we don't know why
> it's done, it's hard to judge if it can be disallowed.
> I must say I don't very much like this idea of special-casing the
> obarray and the symbols interned therein.

I really can't think of any good reason why anyone would unintern a core
symbol --- all the uses I can think of would be better served by either
using advice or let-binding `obarray'. I sometimes use mass-uninterning
to get rid of stale function names when I'm developing an elisp package,
but this technique isn't useful for symbols referenced from pure
storage, and a good alternative is just resetting value and symbol
slots. (In fact, I shouldn't use unintern at all for this hack.) Since
it's neither safe nor useful to unintern core symbols, I don't think
it's worry about whether it's okay to forbid it.

Besides: we already special-case the initial obarray for keywordp.

Anyway, I'd like to get a fix into emacs-24 soon so we can make sure
we've fixed the GC bug. Are you vetoing the general approach used in
this patch? If so, I can look at alternatives.

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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