bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pip Cet]

On Fri, Mar 13, 2020 at 4:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > > Please say something about your notion of "visible". It doesn't affect
> > > > any of the existing C callers of valid_lisp_object_p. Are you talking
> > > > about printing valid_lisp_object_p(x) in a debugger, and not getting
> > > > the expected value? Or something else?
> > >
> > > I'm talking about the behavior documented in the commentary.
> >
> > You're right if your point is the comment should be adjusted to omit
> > the unnecessary, and unused, special behavior on killed buffers.
>
> I don't yet think that function's behavior should be changed.  See
> below.

Okay, I can accept that. I suggest we focus on what you want changed, then?

> > How so? Can you describe a scenario in which Emacs would behave at all
> > differently?
>
> The behavior of live_buffer_p and valid_lisp_object_p changed, and
> those functions weren't "buggy" before.

We're just going to have to agree to disagree about whether changing
an internal-only function counts as a behavor change.

I'm perfectly okay with maintaining those two functions as they were
before, and using reachable_buffer_p or something for the GC function.
Would that work for you?

> > > > (gdb) p current_thread->m_current_buffer
> > > > $3 = (struct buffer *) 0x555556694b10
> > > > (gdb) p valid_lisp_object_p(0x555556694b15)
> > > > $4 = 1
> > > > (gdb) p valid_lisp_object_p(0x555556694b25)
> > > > $5 = 1
> > >
> > > Why do you consider this incorrect?  The Emacs GC is "conservative",
> > > which means it doesn't collect anything that _might_ be a valid Lisp
> > > object.  In what ways does the above violate that contract?
> >
> > GC is conservative; valid_lisp_object_p is documented to be precise: a
> > return value of 1 or 2 means that the object is valid, not that it's
> > potentially valid and potentially nonsense.
>
> But what does "valid" mean in this case?  The part that looks at the
> stack uses the stack-marking routines, and thus inherits the
> "conservative" nature of stack marking.

I don't believe that's correct. valid_lisp_object_p is documented, at
least, to return precisely which object is valid, which one isn't, and
potentially which one we can't say anything about.

> > A buffer should be marked iff it is reachable
> >
> > A buffer is marked iff it is reachable from the heap or it is
> > reachable from the stack and buffer_live_p returns true
> >
> > Therefore, it is invalid for buffer_live_p to return false for a
> > buffer which is reachable from the stack.
>
> This mixes two notions: a "live" buffer and a buffer that should be
> marked.  They are not the same.

No, it doesn't. I never mentioned liveness in the sense of not being
killed, at all.

> Fine, so you are saying that stack marking should disregard whether a
> buffer is "live"?  Then let's make such a change only for stack
> marking, not in a function called from other places.

I agree. I'll prepare a patch.