bug#74547: 31.0.50; igc: assertion failed in buffer.c

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 74547@debbugs.gnu.org,
>  Óscar Fuentes <oscarfv@telefonica.net>, geza.herman@gmail.com
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Sun, 01 Dec 2024 16:18:31 +0100
> 
> Pip Cet <pipcet@protonmail.com> writes:
> 
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >
> >> Pip Cet <pipcet@protonmail.com> writes:
> >
> >>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >>>> Pip Cet <pipcet@protonmail.com> writes:
> >>>> Yes, exactly, json.c. First thing I saw when searching for xfree
> >>>>
> >>>> static void
> >>>> json_parser_done (void *parser)
> >>>> {
> >>>>   struct json_parser *p = (struct json_parser *) parser;
> >>>>   if (p->object_workspace != p->internal_object_workspace)
> >>>>     xfree (p->object_workspace);
> >>>>
> >>>> That at least needs an explanation. I would have expected it to be
> >>>> allocated as root.
> >>>
> >>> Well, the explanation is this comment:
> >>>
> >>>   /* Lisp_Objects are collected in this area during object/array
> >>>      parsing.  To avoid allocations, initially
> >>>      internal_object_workspace is used.  If it runs out of space then
> >>>      we switch to allocated space.  Important note: with this design,
> >>>      GC must not run during JSON parsing, otherwise Lisp_Objects in
> >>>      the workspace may get incorrectly collected. */
> >>
> >> That explains it, indeed :-(.
> >
> > Just to be clear, I think the mixed heap/stack allocation is the right
> > thing to do here, but we need to let both garbage collectors know about
> > the Lisp_Objects we allocated.
> >
> > I think the best way to do that is to use a Lisp_Vector when we run out
> > of stack space. That way, we don't have to worry about forgetting to GC
> > it, and we can use standard functions rather than rolling our own.
> 
> Yeah, I'd prefer using Lisp_Vectors too, and it was actually implemented
> at some point, but removed again, see
> 
>   https://yhetil.org/emacs-devel/87edc1rzig.fsf@gmail.com/
> 
> I vaguely remember a longer thread about GC in json.c at the time. Could
> be that that was before igc became a realistic possibility, don't
> remember.
> 
> And yes, I've forgotten about it, and should actually have fixed this
> long ago :-).

Please be sure to measure performance.  json.c is performance-critical
in many applications nowadays, that's why it was implemented in C.