all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
@ 2021-06-15 15:52 Boruch Baum
  2021-06-15 16:15 ` Lars Ingebrigtsen
  2021-06-15 16:20 ` Eli Zaretskii
  0 siblings, 2 replies; 21+ messages in thread
From: Boruch Baum @ 2021-06-15 15:52 UTC (permalink / raw)
  To: 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-15 15:52 bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX] Boruch Baum
@ 2021-06-15 16:15 ` Lars Ingebrigtsen
  2021-06-15 20:18   ` Boruch Baum
  2021-06-15 16:20 ` Eli Zaretskii
  1 sibling, 1 reply; 21+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-15 16:15 UTC (permalink / raw)
  To: Boruch Baum; +Cc: 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-15 15:52 bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX] Boruch Baum
  2021-06-15 16:15 ` Lars Ingebrigtsen
@ 2021-06-15 16:20 ` Eli Zaretskii
  2021-06-15 20:13   ` Boruch Baum
  2021-06-15 20:39   ` Boruch Baum
  1 sibling, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2021-06-15 16:20 UTC (permalink / raw)
  To: Boruch Baum; +Cc: 49043

> 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?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-15 16:20 ` Eli Zaretskii
@ 2021-06-15 20:13   ` Boruch Baum
  2021-06-15 20:39   ` Boruch Baum
  1 sibling, 0 replies; 21+ messages in thread
From: Boruch Baum @ 2021-06-15 20:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-15 16:15 ` Lars Ingebrigtsen
@ 2021-06-15 20:18   ` Boruch Baum
  2021-06-16  8:19     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 21+ messages in thread
From: Boruch Baum @ 2021-06-15 20:18 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-15 16:20 ` Eli Zaretskii
  2021-06-15 20:13   ` Boruch Baum
@ 2021-06-15 20:39   ` Boruch Baum
  1 sibling, 0 replies; 21+ messages in thread
From: Boruch Baum @ 2021-06-15 20:39 UTC (permalink / raw)
  To: Eli Zaretskii, Lars Ingebrigtsen; +Cc: 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-15 20:18   ` Boruch Baum
@ 2021-06-16  8:19     ` Lars Ingebrigtsen
  2021-06-16  8:26       ` Boruch Baum
  2021-06-18 14:11       ` Stephen Berman
  0 siblings, 2 replies; 21+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-16  8:19 UTC (permalink / raw)
  To: Boruch Baum; +Cc: 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-16  8:19     ` Lars Ingebrigtsen
@ 2021-06-16  8:26       ` Boruch Baum
  2021-06-16  8:51         ` Lars Ingebrigtsen
  2021-06-16 12:04         ` Eli Zaretskii
  2021-06-18 14:11       ` Stephen Berman
  1 sibling, 2 replies; 21+ messages in thread
From: Boruch Baum @ 2021-06-16  8:26 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-16  8:26       ` Boruch Baum
@ 2021-06-16  8:51         ` Lars Ingebrigtsen
  2021-06-16 12:04         ` Eli Zaretskii
  1 sibling, 0 replies; 21+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-16  8:51 UTC (permalink / raw)
  To: Boruch Baum; +Cc: 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-16  8:26       ` Boruch Baum
  2021-06-16  8:51         ` Lars Ingebrigtsen
@ 2021-06-16 12:04         ` Eli Zaretskii
  2021-06-16 17:01           ` Boruch Baum
  1 sibling, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2021-06-16 12:04 UTC (permalink / raw)
  To: Boruch Baum; +Cc: larsi, 49043

> 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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-16 12:04         ` Eli Zaretskii
@ 2021-06-16 17:01           ` Boruch Baum
  2021-06-16 17:10             ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Boruch Baum @ 2021-06-16 17:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-16 17:01           ` Boruch Baum
@ 2021-06-16 17:10             ` Eli Zaretskii
  0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2021-06-16 17:10 UTC (permalink / raw)
  To: Boruch Baum; +Cc: larsi, 49043

> 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?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-16  8:19     ` Lars Ingebrigtsen
  2021-06-16  8:26       ` Boruch Baum
@ 2021-06-18 14:11       ` Stephen Berman
  2021-06-19 12:06         ` Lars Ingebrigtsen
  2021-06-19 15:56         ` Michael Albinus
  1 sibling, 2 replies; 21+ messages in thread
From: Stephen Berman @ 2021-06-18 14:11 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Michael Albinus, Boruch Baum, 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-18 14:11       ` Stephen Berman
@ 2021-06-19 12:06         ` Lars Ingebrigtsen
  2021-06-19 12:12           ` Michael Albinus
  2021-06-19 15:56         ` Michael Albinus
  1 sibling, 1 reply; 21+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-19 12:06 UTC (permalink / raw)
  To: Stephen Berman; +Cc: Michael Albinus, Boruch Baum, 49043

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





^ permalink raw reply related	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-19 12:06         ` Lars Ingebrigtsen
@ 2021-06-19 12:12           ` Michael Albinus
  0 siblings, 0 replies; 21+ messages in thread
From: Michael Albinus @ 2021-06-19 12:12 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stephen Berman, Boruch Baum, 49043

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Any comments?

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

Best regards, Michael.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-18 14:11       ` Stephen Berman
  2021-06-19 12:06         ` Lars Ingebrigtsen
@ 2021-06-19 15:56         ` Michael Albinus
  2021-06-19 19:56           ` Stephen Berman
  2021-06-19 21:41           ` Stephen Berman
  1 sibling, 2 replies; 21+ messages in thread
From: Michael Albinus @ 2021-06-19 15:56 UTC (permalink / raw)
  To: Stephen Berman; +Cc: Lars Ingebrigtsen, Boruch Baum, 49043

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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-19 15:56         ` Michael Albinus
@ 2021-06-19 19:56           ` Stephen Berman
  2021-06-19 21:41           ` Stephen Berman
  1 sibling, 0 replies; 21+ messages in thread
From: Stephen Berman @ 2021-06-19 19:56 UTC (permalink / raw)
  To: Michael Albinus; +Cc: Lars Ingebrigtsen, Boruch Baum, 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-19 15:56         ` Michael Albinus
  2021-06-19 19:56           ` Stephen Berman
@ 2021-06-19 21:41           ` Stephen Berman
  2021-06-20  8:12             ` Boruch Baum
  2021-06-21 12:25             ` Lars Ingebrigtsen
  1 sibling, 2 replies; 21+ messages in thread
From: Stephen Berman @ 2021-06-19 21:41 UTC (permalink / raw)
  To: Michael Albinus; +Cc: Lars Ingebrigtsen, Boruch Baum, 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-19 21:41           ` Stephen Berman
@ 2021-06-20  8:12             ` Boruch Baum
  2021-06-20 14:29               ` Michael Albinus
  2021-06-21 12:25             ` Lars Ingebrigtsen
  1 sibling, 1 reply; 21+ messages in thread
From: Boruch Baum @ 2021-06-20  8:12 UTC (permalink / raw)
  To: Stephen Berman; +Cc: Lars Ingebrigtsen, Michael Albinus, 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-20  8:12             ` Boruch Baum
@ 2021-06-20 14:29               ` Michael Albinus
  0 siblings, 0 replies; 21+ messages in thread
From: Michael Albinus @ 2021-06-20 14:29 UTC (permalink / raw)
  To: Boruch Baum; +Cc: Lars Ingebrigtsen, Stephen Berman, 49043

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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX]
  2021-06-19 21:41           ` Stephen Berman
  2021-06-20  8:12             ` Boruch Baum
@ 2021-06-21 12:25             ` Lars Ingebrigtsen
  1 sibling, 0 replies; 21+ messages in thread
From: Lars Ingebrigtsen @ 2021-06-21 12:25 UTC (permalink / raw)
  To: Stephen Berman; +Cc: Michael Albinus, Boruch Baum, 49043

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2021-06-21 12:25 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-06-15 15:52 bug#49043: 27.1: ibuffer-toggle-filter-group [BUGFIX] Boruch Baum
2021-06-15 16:15 ` Lars Ingebrigtsen
2021-06-15 20:18   ` Boruch Baum
2021-06-16  8:19     ` Lars Ingebrigtsen
2021-06-16  8:26       ` Boruch Baum
2021-06-16  8:51         ` Lars Ingebrigtsen
2021-06-16 12:04         ` Eli Zaretskii
2021-06-16 17:01           ` Boruch Baum
2021-06-16 17:10             ` Eli Zaretskii
2021-06-18 14:11       ` Stephen Berman
2021-06-19 12:06         ` Lars Ingebrigtsen
2021-06-19 12:12           ` Michael Albinus
2021-06-19 15:56         ` Michael Albinus
2021-06-19 19:56           ` Stephen Berman
2021-06-19 21:41           ` Stephen Berman
2021-06-20  8:12             ` Boruch Baum
2021-06-20 14:29               ` Michael Albinus
2021-06-21 12:25             ` Lars Ingebrigtsen
2021-06-15 16:20 ` Eli Zaretskii
2021-06-15 20:13   ` Boruch Baum
2021-06-15 20:39   ` Boruch Baum

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.