Re: Changes in GC and in pure space (was: [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch)

[Pip Cet]

On Thu, Aug 15, 2019 at 9:34 AM Paul Eggert <address@hidden> wrote:
> Pip Cet wrote:
>
> > Here are things I would consider urgent enough to warrant looking at
> > for Emacs 27:
> > - remove code like we have in `Ffset' to detect GC bugs that
> > presumably have been fixed by now
>
> Are you talking about just the code introduced in commit
> 2014-04-03T00:18:08Z!address@hidden
> (01ae0fbf30b74e2490144fceabbf5bc5d96f1ba7), or is some other code involved? 
> I'll
> CC this to dancol to see if he has thoughts.

There's also reference to a GC bug in describe_vector.

> > - make_fixnum called for numbers outside the fixnum range
>
> I installed a patch to master just now to do that.

Thanks!

> > - various places that should detect circular lists but don't (lread.c
> > reading hash tables, for example)
>
> Can you give an example of that problem?

Try reading #s(hash-table data #0=(#0# . #0#))

> > - doubly-evaluated macro arguments (the one I can think of offhand is
> > DUMP_SET_REFERRER, which is harmless, but others might not be)
>
> Do you mean evaluated as in macro expansion, or evaluated as in execution at
> runtime? If the latter, I don't get the problem there. Many other macros 
> assume
> that arguments are side effect free, and some of these cannot be turned into
> inline functions easily.

I think it's likely we still have some places that assume their
arguments are side-effect-free, but whose callers pass arguments with
side effects.

(At least, that's what I'd be looking for once I'm done looking over
the recent major hash table/GC changes to find segfaults like the
below)...

> > - since we appear to be stuck with lazy rehashing for now, the various
> > bugs this causes (I mentioned Fclrhash above)
>
> Sorry, what's the Fclrhash bug?

Calling clrhash on a dumped hash table that hasn't been accessed used
to leave it untouched; now it produces a segfault.

I haven't quite been able to follow how Eli's request went
uncontradicted, but then we ended up making major changes like the
hash table thing, anyway. That leads to this segfault, but I'm not at
all convinced it won't also lead to subtle bugs somewhere else.

(To reproduce the promised segfault, add

(defvar custom-dummy (make-hash-table :test 'eq))
(puthash custom-dummy custom-dummy custom-dummy)

to custom.el, then rebuild and run (clrhash custom-dummy) in Emacs -Q.
Trivial to fix, but apparently not obvious enough to have been caught
in the original changes).