bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Boruch Baum]

I've been having operation ibuffer-toggle-filter-group reliably crash
whenever performed due to it trying to operate on a point beyond
point-max. The culprit seems to be in function ibuffer-map-lines where:

  (delete-region (line-beginning-position)
     	         (line-end-position))))

is being performed instead of:

  (delete-region (line-beginning-position)
	    (min (point-max) (1+ (line-end-position))))

This solves the issue for me.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> I've been having operation ibuffer-toggle-filter-group reliably crash
> whenever performed due to it trying to operate on a point beyond
> point-max. The culprit seems to be in function ibuffer-map-lines where:
>
>   (delete-region (line-beginning-position)
>      	         (line-end-position))))

What does the crash look like?

It's rather surprising, because I don't think `line-end-position' can
ever return a position that's larger than `point-max'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Eli Zaretskii]

> Date: Tue, 15 Jun 2021 11:52:31 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> 
> I've been having operation ibuffer-toggle-filter-group reliably crash
> whenever performed due to it trying to operate on a point beyond
> point-max.

By "crash" do you mean it signals an error?  Or a real crash with a
core dump?

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Boruch Baum]

On 2021-06-15 19:20, Eli Zaretskii wrote:
> By "crash" do you mean it signals an error?  Or a real crash with a
> core dump?

Sorry. It produced a backtrace, though I'm pretty sure I didn't have
toggle-debug-on-error set, so it was a surprise to get that. The
backtrace pointed to a call of function delete-region with a bounds
check problem. I saw that the upper-bound exceeded point-max, put in the
check, and voila.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Boruch Baum]

On 2021-06-15 18:15, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > I've been having operation ibuffer-toggle-filter-group reliably crash
> > whenever performed due to it trying to operate on a point beyond
> > point-max. The culprit seems to be in function ibuffer-map-lines where:
> >
> >   (delete-region (line-beginning-position)
> >      	         (line-end-position))))

Oops. I misquoted the code (because I had submitted the report after I
had made/tested/byte-compiled/over-writte my only local copy). If you look at the
code on the gnu cgit instance, at line 1907, you'll see that it adds one
to the line-end-position before passing the value the function
delete-region.

A similar idiom exists on line 1843, so that may be another bug.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Boruch Baum]

It struck me just now to perform an rzgrep on the debian emacs 27 lisp
directory for the idiom "(1+ (line-end-position)"...

./calendar/todo-mode.el.gz:4254:				 (1+ (line-end-position)))
./calendar/todo-mode.el.gz:4273:	    (delete-region (line-beginning-position) (1+ (line-end-position)))
./calendar/todo-mode.el.gz:4332:					    (1+ (line-end-position))))
./calendar/todo-mode.el.gz:4683:	  (delete-region (line-beginning-position) (1+ (line-end-position)))
./calendar/todo-mode.el.gz:4924:    (setq cat-begin (1+ (line-end-position)))
./international/quail.el.gz:2646:			     (1+ (line-end-position)))))))
./international/quail.el.gz:2650:	  (delete-region (point) (1+ (line-end-position)))
./dired.el.gz:1479:				 (1+ (line-end-position))
./gnus/nnimap.el.gz:277:			   (1+ (line-end-position)))
./obsolete/otodo-mode.el.gz:450:    (let ((begin (1+ (line-end-position))))
./ibuffer.el.gz:1966:	    (delete-region (point) (1+ (line-end-position)))
./ibuffer.el.gz:2030:				    (min (point-max) (1+ (line-end-position))))
./emacs-lisp/smie.el.gz:1457:                            (1+ (line-end-position)) t))
./emacs-lisp/tabulated-list.el.gz:590:      (delete-region (line-beginning-position) (1+ (line-end-position)))
./progmodes/dcl-mode.el.gz:802:  (let* ((default-limit (1+ (line-end-position)))
./eshell/em-unix.el.gz:646:			 (point) (min (1+ (line-end-position))



--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> Oops. I misquoted the code (because I had submitted the report after I
> had made/tested/byte-compiled/over-writte my only local copy). If you look at the
> code on the gnu cgit instance, at line 1907, you'll see that it adds one
> to the line-end-position before passing the value the function
> delete-region.

Right -- so I guess the problem here is that the last line of the buffer
doesn't have a newline...  but skimming the code (I'm not super-familiar
with ibuffer), it seems like the final non-newline line is a summary
line and should be kept out of the sorting/filtering process?  (If
there's a "buffer line" without a newline, it'll mess up the display
after filtering.)

So I think that perhaps the bug is somewhere else, but it's hard to say
without a recipe that reproduces the bug.

Do you have a test case?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Boruch Baum]

On 2021-06-16 10:19, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> Do you have a test case?

I *did* before I fixed it locally with the change, and filed the report.
Another approach to consider would be to put bounds-checking in function
delete-region against (point-min) and (point-max).

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> I *did* before I fixed it locally with the change, and filed the report.

Can you undo the change and come up with a test case?

> Another approach to consider would be to put bounds-checking in function
> delete-region against (point-min) and (point-max).

No, not at all -- if you're giving out-of-bounds values to
delete-region, you have a bug somewhere.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Eli Zaretskii]

> Date: Wed, 16 Jun 2021 04:26:01 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: 49043@debbugs.gnu.org
> 
> Another approach to consider would be to put bounds-checking in function
> delete-region against (point-min) and (point-max).

delete-region already does include such checking, that's why you get
the backtrace: it signals an error.

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Boruch Baum]

On 2021-06-16 15:04, Eli Zaretskii wrote:
> > Date: Wed, 16 Jun 2021 04:26:01 -0400
> > From: Boruch Baum <boruch_baum@gmx.com>
> > Cc: 49043@debbugs.gnu.org
> >
> > Another approach to consider would be to put bounds-checking in function
> > delete-region against (point-min) and (point-max).
>
> delete-region already does include such checking, that's why you get
> the backtrace: it signals an error.

You've missed the point.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Eli Zaretskii]

> Date: Wed, 16 Jun 2021 13:01:08 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: larsi@gnus.org, 49043@debbugs.gnu.org
> 
> > > Another approach to consider would be to put bounds-checking in function
> > > delete-region against (point-min) and (point-max).
> >
> > delete-region already does include such checking, that's why you get
> > the backtrace: it signals an error.
> 
> You've missed the point.

Sorry about that.  Could you please point out what I missed?

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Stephen Berman]

On Wed, 16 Jun 2021 10:19:23 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Boruch Baum <boruch_baum@gmx.com> writes:
>
>> Oops. I misquoted the code (because I had submitted the report after I
>> had made/tested/byte-compiled/over-writte my only local copy). If you look at the
>> code on the gnu cgit instance, at line 1907, you'll see that it adds one
>> to the line-end-position before passing the value the function
>> delete-region.
>
> Right -- so I guess the problem here is that the last line of the buffer
> doesn't have a newline...  but skimming the code (I'm not super-familiar
> with ibuffer), it seems like the final non-newline line is a summary
> line and should be kept out of the sorting/filtering process?  (If
> there's a "buffer line" without a newline, it'll mess up the display
> after filtering.)
>
> So I think that perhaps the bug is somewhere else, but it's hard to say
> without a recipe that reproduces the bug.
>
> Do you have a test case?

I do.  It's the result of an error being raised in Tramp.  Here's the
recipe (reliably reproducible on

GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.29,
cairo version 1.17.4) of 2021-06-06 built on strobelfs 
Repository revision: 218d2d1509673d8bc67014558a31f5d0da1be5c6
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
Configured using: 'configure --with-native-compilation 'CFLAGS=-Og -g3''
Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS
GSETTINGS HARFBUZZ JPEG LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB
):

0. emacs -Q
1. Create a nonempty ZIP file test.zip (content is irrelevant).
2. Visit the directory containing test.zip in Dired.
3. Type `M-x load-library RET dired-x RET'.
4. With point on the Dired line containing test.zip type `M-!', which
   prompts with "! on test.zip {3 guesses} [unzip]:" and type RET to
   execute unzip (this of course requires having the unzip program).
5. With point still on the test.zip line type `D' and at the prompt `y'
   to delete the ZIP file.
=> This raises a file-error (see below), but the ZIP file is deleted.
6. Type `M-x ibuffer'.
=> This raises the error "tramp-error: Method ‘archive’ is not known."
7. In the *Ibuffer* buffer type `g'.
=> This raises the error "ibuffer-current-state-list: Args out of range:
   #<buffer *Ibuffer*>, 280, 332". 

The latter error is apparently what the OP reported, and it's because
the Ibuffer buffer is corrupted; here's what it looks like after step 7,
except for the last character `|', which I added to show EOB:

[ Default ]
  %  tmp                      802 Dired by name    /tmp/
 *%  *Messages*               754 Messages         
  %  steve                   4171 Dired by name    ~/
     *scratch*                145 Lisp Interaction 
 *   *Shell Command ...       114 Fundamental      
     *tramp/archive ...         0 Fundamental      |

In other words, as you deduced, the summary line is missing, so the
attempt to do delete-region errors out.

The corruption of the Ibuffer buffer is due to the error raised at step
6, which is triggered in ibuffer-redisplay-engine during the execution
of ibuffer-insert-filter-group.  This errors prevent the subsequent
execution of ibuffer-update-title-and-summary, resulting in the above
corrupted Ibuffer display.

As for the error at step 5, which is the cause of the following errors,
it is raised in tramp-gvfs-maybe-open-connection.  Here's what the
*Messages* buffer contains after step 5:

Deleting... 
Waiting for git... [2 times]
Tramp: Opening connection for file%3A%2F%2F%2Ftmp%2Ftest.zip using archive...failed
file-error: org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code1 Error when getting information for file “/tmp/test.zip”: No such file or directory

Step 3 of the recipe is necessary to raise the above errors.  I guess
dired-guess-shell-command triggers Tramp file handling.  CCing Michael
Albinus, who should be able to solve the problem.

Steve Berman

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> I do.  It's the result of an error being raised in Tramp.  Here's the
> recipe (reliably reproducible on

Thanks for the thorough recipe -- I was able to reproduce the problem,
too.

> 6. Type `M-x ibuffer'.
> => This raises the error "tramp-error: Method ‘archive’ is not known."

Here's the backtrace for that:

Debugger entered--Lisp error: (user-error "Method ‘archive’ is not known.")
  signal(user-error ("Method ‘archive’ is not known."))
  tramp-error((tramp-file-name "archive" nil nil "file%3A%2F%2F%2Ftmp%2Ffoo.zip" nil "" nil) user-error "Method `%s' is not known." "archive")
  apply(tramp-error (tramp-file-name "archive" nil nil "file%3A%2F%2F%2Ftmp%2Ffoo.zip" nil "" nil) user-error "Method `%s' is not known." "archive")
  tramp-user-error((tramp-file-name "archive" nil nil "file%3A%2F%2F%2Ftmp%2Ffoo.zip" nil "" nil) "Method `%s' is not known." "archive")
  tramp-dissect-file-name("/archive:file%3A%2F%2F%2Ftmp%2Ffoo.zip:")
  tramp-file-name-handler(expand-file-name "" "/archive:file%3A%2F%2F%2Ftmp%2Ffoo.zip:")
  file-name-case-insensitive-p("")
  abbreviate-file-name("")
  ibuffer--abbreviate-file-name("")
  ibuffer-make-column-filename(#<buffer *tramp/archive file%3A%2F%2F%2Ftmp%2Ffoo.zip*> 32)
  ibuffer-make-column-filename-and-process(#<buffer *tramp/archive file%3A%2F%2F%2Ftmp%2Ffoo.zip*> 32)
  #f(compiled-function (buffer mark) #<bytecode 0xa9479abf87c6c30>)(#<buffer *tramp/archive file%3A%2F%2F%2Ftmp%2Ffoo.zip*> 32)
  ibuffer-insert-buffer-line(#<buffer *tramp/archive file%3A%2F%2F%2Ftmp%2Ffoo.zip*> 32 #f(compiled-function (buffer mark) #<bytecode 0xa9479abf87c6c30>))
  ibuffer-insert-filter-group("Default" "Default" "" #f(compi
  ibuffer-redisplay-engine(((#<buffer tmp> . 32) (#<buffer *C
  ibuffer-update(nil)
  ibuffer(nil)
  funcall-interactively(ibuffer nil)

> Step 3 of the recipe is necessary to raise the above errors.  I guess
> dired-guess-shell-command triggers Tramp file handling.  CCing Michael
> Albinus, who should be able to solve the problem.

3) does indeed seem to be a Tramp problem, but I wonder if ibuffer
should be more resilient here?  That is, to avoid messing up the
ibuffer, we could do something like:

diff --git a/lisp/ibuffer.el b/lisp/ibuffer.el
index 9088f31053..73ddfb260c 100644
--- a/lisp/ibuffer.el
+++ b/lisp/ibuffer.el
@@ -1184,7 +1184,11 @@ ibuffer-buffer-file-name
 (defun ibuffer--abbreviate-file-name (filename)
   "Abbreviate FILENAME using `ibuffer-directory-abbrev-alist'."
   (let ((directory-abbrev-alist ibuffer-directory-abbrev-alist))
-    (abbreviate-file-name filename)))
+    (condition-case ()
+        ;; This may fail if the filename is a Tramp filename that is
+        ;; invalid.
+        (abbreviate-file-name filename)
+      (error filename))))
 
 (define-ibuffer-op ibuffer-do-save ()
   "Save marked buffers as with `save-buffer'."

Any comments?

(This would be in addition to actually fixing 3).)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Any comments?

I'm working on this, pls give me some time for analysis.

Best regards, Michael.

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Michael Albinus]

Stephen Berman <stephen.berman@gmx.net> writes:

Hi Steve,

> I do.  It's the result of an error being raised in Tramp.  Here's the
> recipe (reliably reproducible on
>
> GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.29,
> cairo version 1.17.4) of 2021-06-06 built on strobelfs 
> Repository revision: 218d2d1509673d8bc67014558a31f5d0da1be5c6
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
> Configured using: 'configure --with-native-compilation 'CFLAGS=-Og -g3''
> Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS
> GSETTINGS HARFBUZZ JPEG LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP
> NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
> TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB
> ):
>
> 0. emacs -Q
> 1. Create a nonempty ZIP file test.zip (content is irrelevant).
> 2. Visit the directory containing test.zip in Dired.
> 3. Type `M-x load-library RET dired-x RET'.
> 4. With point on the Dired line containing test.zip type `M-!', which
>    prompts with "! on test.zip {3 guesses} [unzip]:" and type RET to
>    execute unzip (this of course requires having the unzip program).
> 5. With point still on the test.zip line type `D' and at the prompt `y'
>    to delete the ZIP file.
> => This raises a file-error (see below), but the ZIP file is deleted.
> 6. Type `M-x ibuffer'.
> => This raises the error "tramp-error: Method ‘archive’ is not known."
> 7. In the *Ibuffer* buffer type `g'.
> => This raises the error "ibuffer-current-state-list: Args out of range:
>    #<buffer *Ibuffer*>, 280, 332". 

Thanks for this. Apparently, it is the same error as bug#49030, I'll
merge both. A fix will follow soon, pls check whether it works for you.

> Steve Berman

Best regards, Michael.

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Stephen Berman]

On Sat, 19 Jun 2021 17:56:24 +0200 Michael Albinus <michael.albinus@gmx.de> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> 0. emacs -Q
>> 1. Create a nonempty ZIP file test.zip (content is irrelevant).
>> 2. Visit the directory containing test.zip in Dired.
>> 3. Type `M-x load-library RET dired-x RET'.
>> 4. With point on the Dired line containing test.zip type `M-!', which
>>    prompts with "! on test.zip {3 guesses} [unzip]:" and type RET to
>>    execute unzip (this of course requires having the unzip program).
>> 5. With point still on the test.zip line type `D' and at the prompt `y'
>>    to delete the ZIP file.
>> => This raises a file-error (see below), but the ZIP file is deleted.
>> 6. Type `M-x ibuffer'.
>> => This raises the error "tramp-error: Method ‘archive’ is not known."
>> 7. In the *Ibuffer* buffer type `g'.
>> => This raises the error "ibuffer-current-state-list: Args out of range:
>>    #<buffer *Ibuffer*>, 280, 332". 
>
> Thanks for this. Apparently, it is the same error as bug#49030, I'll
> merge both.

Ah, right, I saw that report but then unfortunately forgot about it; it
would have saved me quite a bit of time...

>             A fix will follow soon, pls check whether it works for you.

Looking forward to it!

Steve Berman

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Stephen Berman]

On Sat, 19 Jun 2021 17:56:24 +0200 Michael Albinus <michael.albinus@gmx.de> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
> Hi Steve,
>
>> I do.  It's the result of an error being raised in Tramp.  Here's the
>> recipe (reliably reproducible on
>>
>> GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.29,
>> cairo version 1.17.4) of 2021-06-06 built on strobelfs 
>> Repository revision: 218d2d1509673d8bc67014558a31f5d0da1be5c6
>> Repository branch: master
>> Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
>> Configured using: 'configure --with-native-compilation 'CFLAGS=-Og -g3''
>> Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS
>> GSETTINGS HARFBUZZ JPEG LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP
>> NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
>> TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB
>> ):
>>
>> 0. emacs -Q
>> 1. Create a nonempty ZIP file test.zip (content is irrelevant).
>> 2. Visit the directory containing test.zip in Dired.
>> 3. Type `M-x load-library RET dired-x RET'.
>> 4. With point on the Dired line containing test.zip type `M-!', which
>>    prompts with "! on test.zip {3 guesses} [unzip]:" and type RET to
>>    execute unzip (this of course requires having the unzip program).
>> 5. With point still on the test.zip line type `D' and at the prompt `y'
>>    to delete the ZIP file.
>> => This raises a file-error (see below), but the ZIP file is deleted.
>> 6. Type `M-x ibuffer'.
>> => This raises the error "tramp-error: Method ‘archive’ is not known."
>> 7. In the *Ibuffer* buffer type `g'.
>> => This raises the error "ibuffer-current-state-list: Args out of range:
>>    #<buffer *Ibuffer*>, 280, 332". 
>
> Thanks for this. Apparently, it is the same error as bug#49030, I'll
> merge both. A fix will follow soon, pls check whether it works for you.

I rebuilt with your patch, and confirm it fixes the error in step 5
above, and hence the subsequent errors do not occur.  Thanks!

Since essentially my recipe was previously reported in bug#49030, I
think that bug can be closed.  But before closing bug#49043, perhaps
Boruch Baum should chime in, since he only reported the problem in
Ibuffer.  I showed this can be triggered by the Tramp bug, but perhaps
there are other triggers too, and if so some additional safeguard in
Ibuffer such as what Lars suggested may be appropriate.

Steve Berman

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Boruch Baum]

On 2021-06-19 23:41, Stephen Berman wrote:
> Since essentially my recipe was previously reported in bug#49030, I
> think that bug can be closed.  But before closing bug#49043, perhaps
> Boruch Baum should chime in, since he only reported the problem in
> Ibuffer.  I showed this can be triggered by the Tramp bug, but perhaps
> there are other triggers too, and if so some additional safeguard in
> Ibuffer such as what Lars suggested may be appropriate.

Thanks for figuring this out, Steve. Your recipe may be what happened to
me, but if so the steps were taken over the course of a few days. I
remember that at some point days ago I did see and ignore a 'method
archive' error.

I'm okay with closing this bug as is.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Michael Albinus]

Boruch Baum <boruch_baum@gmx.com> writes:

Hi Boruch,

> I'm okay with closing this bug as is.

Done for Emacs 28 (Tramp 2.5). Since there won't be another Emacs 27
release, the patch isn't merged in the emacs-27 branch.

Best regards, Michael.

bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> I showed this can be triggered by the Tramp bug, but perhaps
> there are other triggers too, and if so some additional safeguard in
> Ibuffer such as what Lars suggested may be appropriate.

I think Michael's fix should be sufficient here, after looking at this
again.  `abbreviate-file-name' isn't supposed to bug out, so we'll see
breakages throughout Emacs if it does, so adding special code to ibuffer
in this case to handle it wouldn't be productive.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no