GNU bug report logs - #38456
27.0.50; Assertion failure in 'smerge-match-conflict'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38456 in the body.
You can then email your comments to 38456 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: 27.0.50; Assertion failure in 'smerge-match-conflict'
Date: Mon, 2 Dec 2019 10:54:46 +0100

Whenever git reports conflicts in a file, Emacs automatically enters
'smerge-mode' when I visit that file and moves point to the first
conflict in its buffer.  When 'debug-on-error' is non-nil and there is
no further conflict, typing C-c ^ n to invoke 'smerge-next' fails as

Debugger entered--Lisp error: (cl-assertion-failed ((< orig-point (match-end 0)) nil))
  cl--assertion-failed((< orig-point (match-end 0)))
  smerge-match-conflict()
  smerge-refine()
  smerge-next(1)
  funcall-interactively(smerge-next 1)
  call-interactively(smerge-next nil nil)
  command-execute(smerge-next)

Whatever that means, it makes Emacs behave erratically from now on,
like no more popping up menu bar items or not recognizing some of my
key bindings.  Quitting the debugger mitigates that but apparently
still leaves 'smerge-mode' unusable and I have to revert the buffer.
Note that all this happens in a situation where I am usually more
occupied about the reasons of the conflicts and how to resolve them
then about how the underlying resolution mechanism works.

I've been observing this behavior for years and never got around
reporting it because I always tried to understand the underlying
behaviors of 'smerge-match-conflict' and the debugger first.
Admittedly, I failed.  Does anyone have an idea about what goes on
here internally and how to fix that?

TIA, martin


In GNU Emacs 27.0.50 (build 63, x86_64-w64-mingw32)
 of 2019-12-01 built on MACHNO

Message #8 received at 38456 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38456 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
Date: Sat, 18 Jan 2020 11:06:58 +0100

martin rudalics <rudalics <at> gmx.at> writes:

> Whenever git reports conflicts in a file, Emacs automatically enters
> 'smerge-mode' when I visit that file and moves point to the first
> conflict in its buffer.  When 'debug-on-error' is non-nil and there is
> no further conflict, typing C-c ^ n to invoke 'smerge-next' fails as
>
> Debugger entered--Lisp error: (cl-assertion-failed ((< orig-point (match-end 0)) nil))
>   cl--assertion-failed((< orig-point (match-end 0)))
>   smerge-match-conflict()
>   smerge-refine()
>   smerge-next(1)
>   funcall-interactively(smerge-next 1)
>   call-interactively(smerge-next nil nil)
>   command-execute(smerge-next)
>
> Whatever that means, it makes Emacs behave erratically from now on,
> like no more popping up menu bar items or not recognizing some of my
> key bindings.  Quitting the debugger mitigates that but apparently
> still leaves 'smerge-mode' unusable and I have to revert the buffer.
> Note that all this happens in a situation where I am usually more
> occupied about the reasons of the conflicts and how to resolve them
> then about how the underlying resolution mechanism works.
>
> I've been observing this behavior for years and never got around
> reporting it because I always tried to understand the underlying
> behaviors of 'smerge-match-conflict' and the debugger first.
> Admittedly, I failed.  Does anyone have an idea about what goes on
> here internally and how to fix that?
>
> TIA, martin

Copying in Stefan Monnier as the author of smerge.

Best regards,
Stefan Kangas

Message #11 received at 38456 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38456 <at> debbugs.gnu.org
Subject: Re: bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
Date: Tue, 21 Jan 2020 14:24:23 -0500

> Whenever git reports conflicts in a file, Emacs automatically enters
> 'smerge-mode' when I visit that file and moves point to the first
> conflict in its buffer.  When 'debug-on-error' is non-nil and there is
> no further conflict, typing C-c ^ n to invoke 'smerge-next' fails as
>
> Debugger entered--Lisp error: (cl-assertion-failed ((< orig-point (match-end 0)) nil))
>   cl--assertion-failed((< orig-point (match-end 0)))
>   smerge-match-conflict()
>   smerge-refine()
>   smerge-next(1)
>   funcall-interactively(smerge-next 1)
>   call-interactively(smerge-next nil nil)
>   command-execute(smerge-next)

Oh, yes, thank you.  I've suffered through those many times as well ;-)
The patch below should fix it.

Eli, is it OK to put it into `emacs-27`?
OT1H it's an old bug, so there's no urgency, but OTOH it's "obviously
safe" (turns an assertion failure into a `search-failed` signal).


        Stefan


diff --git a/lisp/vc/smerge-mode.el b/lisp/vc/smerge-mode.el
index d4984bbd38..85868b91ec 100644
--- a/lisp/vc/smerge-mode.el
+++ b/lisp/vc/smerge-mode.el
@@ -797,7 +797,10 @@ smerge-match-conflict
 	       (filename (or (match-string 1) ""))
 
 	       (_ (re-search-forward smerge-end-re))
-	       (_ (cl-assert (< orig-point (match-end 0))))
+	       (_ (when (< (match-end 0) orig-point)
+	            ;; Point is not within the conflict we found,
+	            ;; so this conflict is not ours.
+	            (signal 'search-failed (list smerge-begin-re))))
 
 	       (lower-end (match-beginning 0))
 	       (end (match-end 0))

Message #14 received at 38456 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, 38456 <at> debbugs.gnu.org
Subject: Re: bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
Date: Tue, 21 Jan 2020 21:54:16 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Tue, 21 Jan 2020 14:24:23 -0500
> Cc: 38456 <at> debbugs.gnu.org
> 
> Eli, is it OK to put it into `emacs-27`?

Yes, thanks.

Message #19 received at 38456-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 38456-done <at> debbugs.gnu.org
Subject: Re: bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
Date: Tue, 21 Jan 2020 15:59:04 -0500

>> Eli, is it OK to put it into `emacs-27`?
> Yes, thanks.

Done,


        Stefan

Message #22 received at 38456 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 38456 <at> debbugs.gnu.org
Subject: Re: bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
Date: Wed, 22 Jan 2020 18:44:56 +0100

> Oh, yes, thank you.  I've suffered through those many times as well ;-)
> The patch below should fix it.

Thanks for the fix.  I'll check the next time I see a conflict.  One
thing that should be fixed too, if easily possible, is to gray out the
previous/next conflict menu entries whenever we are at the first/last
conflict.  Smerging can be a painful job (often enough I don't even know
whether the upper or lower represents the one I want to keep) so
avoiding any possible confusions should be a main goal IMHO.

martin

Previous Next

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