GNU bug report logs - #76538
31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs.

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, Helmut Eller <eller.helmut <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, joaomoreira <at> gmx.se,
 76538 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using
 magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some
 random ways blocks GNU Emacs.
Date: Mon, 03 Mar 2025 12:33:34 +0100

Pip Cet <pipcet <at> protonmail.com> writes:

> Here's my current patch series for finalizing markers.  Still needs
> testing to see whether it actually avoids the problem (or will once we
> stop the world for finalizers, as we should), but it doesn't crash
> immediately.
>
> BTW, I'm currently running with a background thread eagerly triggering
> GC, which allowed me to find the missing bt.function trace, but hasn't
> uncovered other bugs so far.  So that is concurrent GC, even if it's
> unlikely to be a performance win right now :-)

:-).

> I have no idea why I hit the assert which required the second patch. It
> seems to me like a bug in the xdisp.c code, but it's xdisp.c, so who
> knows?

Yeah, that doesn't look right. Normally, string_char_and_length should
have been used to get characters from a C string.

> Even though we now emulate the alloc.c code quite precisely, I think
> feature/igc will accumulate many more markers than alloc.c, since weak
> objects are collected quite rarely by MPS, IME.  Maybe we need to mark
> "automatic" markers which are never exposed to Lisp and splat them in
> DO_MARKERS if there are too many of them?
>
> A more convoluted approach would be to alternate between considering
> markers and calculating the charpos for the "best" known marker: do one
> marker, then one character, repeat.  That sort of thing is good for
> theoretical complexity but rarely useful in practice...

I'd like to see something not using markers at all, TBH.

Otherwise, LGTM. Only thing I saw is this:

> +static void
> +finalize_marker (struct Lisp_Marker *m)
> +{
> +  if (m->buffer && BUF_MARKERS (m->buffer))
                      ^^^^^^^^^^^
                      NILP

Previous Next

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