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

Previous Next

Package: emacs;

Reported by: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>

Date: Wed, 2 Apr 2014 07:45:05 UTC

Severity: important

Tags: moreinfo

Merged with 15583, 15688, 15719, 15972, 16278, 16521, 17167, 17184

Found in version 24.3.50

Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>

Bug is archived. No further changes may be made.

Full log


Message #131 received at 17168 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: rms <at> gnu.org
Cc: dmantipov <at> yandex.ru, 17168 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#17168: 24.3.50; Segfault at mark_object
Date: Sun, 06 Apr 2014 11:10:38 -0700
[Message part 1 (text/plain, inline)]
On 04/06/2014 11:00 AM, Richard Stallman wrote:
> You accumulate a list of uninterned symbols whose names are pure.  Why
> make this into a hash table 

To eliminate duplicates, of which there would otherwise be many.

> and then a vector?  

Because that's the best structure to fit in pure storage: the set of
needed symbols never changes, so why *not* turn it into a vector?

> A list should suffice.

No, it really doesn't.

> Or maybe some (or even all) uninterned symbols with pure string names
> should be freed like all other symbols when not pointed to. 

And how do you tell whether they're pointed to without marking the
pointing objects? If you try to mark objects in pure storage, you defeat
the whole point. This change is *exactly* what you need to decide
whether something points to a given symbol.

> check whether the name is pure.

Absolutely not: that's what got us into this mess in the first place.
The purify of a symbol's name should have no bearing on how we treat
that symbol. What matters is whether pure storage refers to an object;
the some of these objects are symbols with pure names is irrelevant.
Please, stop talking about the problem in terms of "symbols whose names
are pure".

Can everyone please stop bikeshedding this? Please read and review the
actual patch instead of suggesting non-solutions. The actual approach is
the simplest general approach that will preserve existing performance
characteristics. The only viable equally simple approach is simply
removing pure storage, and if pure storage works (it amounts to a
primitive kind of generational GC), we might as well keep it.

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

This bug report was last modified 11 years and 47 days ago.

Previous Next


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