GNU bug report logs - #74547
31.0.50; igc: assertion failed in buffer.c

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 74547 <at> debbugs.gnu.org, Óscar Fuentes <oscarfv <at> telefonica.net>
Subject: bug#74547: 31.0.50; igc: assertion failed in buffer.c
Date: Sun, 01 Dec 2024 13:39:09 +0100

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

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>> Pip Cet <pipcet <at> protonmail.com> writes:
>>>
>>>> I think it's unlikely this particular vector is a closure, FWIW, because
>>>> the first slot of a closure vector is always a fixnum.
>>>
>>> I agree.
>>>
>>> I've now checked all the possible PVEC types, and the only ones that fit
>>> size 6 are normal vectors, closures, or records. I also don't believe
>>> that it's a closure because of the fixnum. And records (SQLite) seem a
>>> bit unlikely.
>>
>> Hm, reading Oscar's report again - he was using LSP. Maybe it's
>> something in the parser.
>
> You mean the JSON code? Because I'm just looking at that and it doesn't
> appear to be protecting its Lisp_Objects at all; but I'm not a hundred
> percent sure LSP uses the JSON code.

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.

>
> In either case, we need to fix json.c, I'll try to do that next.
>
> Pip

Thanks!

Previous Next

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