Subject: bug#79200: 31.0.50; Duplicated elements for '#<marker at' in buffer-undo-list

From: Gerd Möllmann <[email-masked]>
Date: Thu, 14 Aug 2025 07:19:44 +0200

Gerd Möllmann <[email-masked]> writes:

> Alan Mackenzie <[email-masked]> writes:
>
>> For what it's worth, I put next--marker-id into my Emacs, just as a
>> counter, nothing else.
>>
>> In my emacs -Q, I do C-h v next--marker-id like you did, and a repeated
>> g to refresh it.  I get just 76 markers made at each iteration.
>
> Also interesting. With emacs -Q -nw, I get a delta of ca. 140, and in
> the GUI (mac) I get 270.
>
>> That makes your 472 look high indeed.  Might it possibly be there's a
>> bug with DEFVAR_INT somewhere, and that 472 = 8 * 59 has wrongly got the
>> 3 type bits in it, and is really just 59?  Just a suggestion.
>
> I think that's unlikely. There are a lot such defvar, and I think
> someone would have noticed such a bug.

So, with the patches I sent, plus a variable I've added, I can see that
compact_undo_list now removes entries from the undo-list. Question is is
it enough to be practical?

I'm afraid I can't answer that - it took me 4 months and a port of igc
to mac to notice the problem to begin with. 

@Oscar: can you perhaps give it a try in the real world?

modified   src/alloc.c
@@ -5832,7 +5832,10 @@ compact_undo_list (Lisp_Object buffer)
 	  Lisp_Object marker = Fmarker_with_id (id, buffer);
 #ifdef HAVE_MPS
 	  if (NILP (marker))
-	    *prev = XCDR (tail);
+	    {
+	      ++n_compacted;
+	      *prev = XCDR (tail);
+	    }
 	  else
 	    prev = xcdr_addr (tail);
 #else
@@ -7709,6 +7712,9 @@ init_alloc (void)
 void
 syms_of_alloc (void)
 {
+  DEFVAR_INT ("n-compacted", n_compacted, doc : /**/);
+  n_compacted = 0;
+
   DEFVAR_INT ("gc-cons-threshold", gc_cons_threshold,
 	      doc: /* Number of bytes of consing between garbage collections.