GNU bug report logs - #70824
29.3; Run time error in `dabbrev-completion'

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Matt Armstrong <matt <at> rfc20.org>
Cc: 70824 <at> debbugs.gnu.org
Subject: bug#70824: 29.3; Run time error in `dabbrev-completion'
Date: Wed, 08 May 2024 16:24:15 +0300

> Date: Tue, 7 May 2024 12:52:56 -0700
> From:  Matt Armstrong via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Debugging this further (sorry, still no repro so I'm debugging my live 
> image), I think this was introduced a few years ago in commit 
> 2d0085f756572856a2ed8d1bf043b59195a3e3f3 and partially fixed in commit 
> d0975d7db03c231a3db5a1cd0edaf41094d43f0d.
> 
> Those commits introduced a feature where `dabbrev--find-expansion' 
> considers the components of a buffer's file name as completion 
> candidates. It does this by creating a temp buffer containing the 
> components.
> 
> The problem is that this temp buffer is immediately killed, yet dabbrev 
> variables still hold references to it. The second commit above correctly 
> removes the killed buffer from `dabbrev--friend-buffer-list', but did 
> not handle the case where `dabbrev--last-buffer' or 
> `dabbrev--last-buffer-found' happened to be the just-killed buffer.

Thanks for the analysis.

> I can think of two approaches:
> 
>   - continual with the "manual GC" approach and scrub more dabbrev vars 
> of this killed buffer.
>   - handle the killed buffer gracefully by using buffer-live-p 
> consistently, instead using checks against nil.

I think we should do both.

Can you suggest a patch along these lines?

Previous Next

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