bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39962: 27.0.90; Crash in Emacs 27.0.90


From: Pieter van Oostrum
Subject: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 16:16:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.90 (darwin)

Pip Cet <address@hidden> writes:

> I'm not sure this is related, but in looking over the code I spotted a
> bit of confusion in the garbage collector between checking a buffer is
> "live" (in the sense that it has not been killed) and checking it's
> live in the sense that it needs to be preserved by GC: evaluating this
> code in *scratch* causes a segfault at least some of the time.
>
> (prog1
>     (let ((temp-buffer (generate-new-buffer " *temp*")))
>       (prog1
>           temp-buffer
>         (kill-buffer temp-buffer)
>         (setq temp-buffer nil)))
>   (garbage-collect))

That crash shouldn't happen, so it has to be found what causes it.

Looking through the code of kill-buffer, I also spotted something that
surprised me. I don't thing it is related to the current crash, but I
want to mention it anyway.

In various places we find the following or similar code:

    /* If the hooks have killed the buffer, exit now.  */
    if (!BUFFER_LIVE_P (b))
      return unbind_to (count, Qt);

But after running the Query functions (line 1724-1732) this is not done.
Now in most cases, because these functions just return true or false,
they will not kill the buffer, but there is no restriction
for them to do that.
So before checking whether the buffer is still modified (line
1734-1742), shouldn't it also check if the buffer is still live?


-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]





reply via email to

[Prev in Thread] Current Thread [Next in Thread]