bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pip Cet]

On Wed, Mar 11, 2020 at 7:34 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > Did you audit all the users of this function, both direct and
> > > indirect?  Some of them are outside of GC.
> >
> > Thanks for the comment; I just re-checked, and they look fine to me.
>
> ??? Fine in what way?

It doesn't affect visible behavior of any callers, except in the case
where the previous behavior was buggy.

> One of the callers is live_buffer_p, which is
> called by valid_lisp_object_p, which is expected to return a special
> value for dead buffers.  Your change will break that, no?

Who's expecting valid_lisp_object_p to return a special value for dead buffers?

The only calls to it that I see check merely whether the return value
is != 0 or > 0, both of which tests remain invariant. Am I missing
something?

What confused me is that live_buffer and live_buffer_p both exist and
do wildly different things. But as you correctly point out, we
shouldn't fix that on the release branch.

> IOW, you are changing the semantics of "live buffer", for a reason
> that can hardly justify that.

I'm most certainly not changing the semantics of live_buffer, if
that's what you're worried about. I am changing the semantics of
live_buffer_p, which is an internal function, and my initial patch
also changed the return value of valid_lisp_object_p, to another value
that would be treated equivalently. If there are objections to that,
we can easily distinguish the two cases.

And I think "so we don't collect reachable objects" is a fairly good
reason, generally.

> That doesn't sound economical to me; it
> will certainly make it much harder for me to agree to make the change
> on the release branch.

I think you've made perfectly clear that you don't want this patch on
the release branch, though I'm not sure I understand the reasoning for
that.

> The problem you are trying to solve is rare

I think it would become much less rare with lexical binding in effect,
at least when the code's byte-compiled.

> and obscure,

IME, test cases often are, even if they test for real and common problems.

> since this code was with us since 20 years ago without
> anyone bumping into it,

That we know of. They might have just accrued it to random Emacs crashes.