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

[Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Óscar Fuentes <oscarfv@telefonica.net> writes:
>
>> While editing a .dart file with lsp-mode.
>
> Thanks Oscar. That's a difficult one.

I agree.

>> #3  0x00005555559c1384 in mps_lib_assert_fail
>>     (condition=0x555555a4a157 "size > 0", line=579, file=0x555555a47782 "buffer.c")
>>     at /home/oscar/dev/other/mps/code/mpsliban.c:87
>> #4  BufferFill
>> #5  0x00005555559f2da0 in amcSegFix (seg=0x7fffb820d070, ss=0x7fffffff9fc0, refIO=0x7fffffff99d0)
>>         trace = <optimized out>
>> #6  0x0000555555990b8c in _mps_fix2 (mps_ss=0x7fffffff9fc8, mps_ref_io=0x7fffffff9a10)
>>         res = <optimized out>
>> #7  0x0000555555903cac in fix_lisp_obj (ss=0x7fffffff9fc8, pobj=0x7fff89f0e000)
>>     at ../../emacs/src/igc.c:998
>>         res = 32767
>>         client = 0x7fff93f2f7d0
>>         base = 0x7fff93f2f7d0
>>         p = 0x7fff89f0e000
>> --Type <RET> for more, q to quit, c to continue without paging--
>>         word = 140735675561940
>>         tag = 4
>>         _ss = 0x7fffffff9fc8
>>         _mps_zs = 22
>>         _mps_ufs = 549755846664
>>         _mps_wt = 32768
>>         _mps_w = 133143986160
>> #8  0x0000555555904160 in fix_array (ss=0x7fffffff9fc8, array=0x7fff89f0e000, n=6)
>>     at ../../emacs/src/igc.c:1233
>>         res = 30
>>         i = 0
>>         _ss = 0x7fffffff9fc8
>>         _mps_zs = 22
>>         _mps_ufs = 549755813896
>>         _mps_wt = <optimized out>
>>         _mps_w = 133143986160
>> #9  0x000055555590674b in fix_vectorlike (ss=0x7fffffff9fc8, v=0x7fff89f0dff0)
>>     at ../../emacs/src/igc.c:1974
>>         res = 32767
>>         size = 6
>>         _ss = 0x7fffffff9fc8
>>         _mps_zs = 22
>>         _mps_ufs = 549755813896
>>         _mps_wt = <optimized out>
>>         _mps_w = 133143986160
>> #10 0x0000555555908d53 in fix_vector (ss=0x7fffffff9fc8, v=0x7fff89f0dff0)
>> --Type <RET> for more, q to quit, c to continue without paging--
>>     at ../../emacs/src/igc.c:2646
>>         obj_ = 0x7fff89f0dff0
>>         res = 0
>>         _ss = 0x7fffffff9fc8
>>         _mps_zs = 22
>>         _mps_ufs = 549755813896
>>         _mps_wt = <optimized out>
>>         _mps_w = 133143986160
>> #11 0x00005555559061d4 in dflt_scan_obj
>>     (ss=0x7fffffff9fc8, base_start=0x7fff89f0dff0,
>>     base_limit=0x7fff89f0f000, closure=0x0)
>
> I've stripped the rest of the backtrace because it's probably not
> too relevant.
>
> What Emacs is doing here is allocate a cons, which triggers a GC step
> because the allocation point needs more memory. In this GC step, we
> scans a memory area containing a vector (or vectorlike) containing 6
> elements. The first element is a string for which MPS_FIX1 says it needs
> to be passed to MPS_FIX2, but MPS_FIX2 aborts.
>
> I have no idea why that is. I've added Pip in CC, maybe he has ideas.

I think the relevant part is that the IGC header of the object passed to
_mps_fix2 is incorrect: it claims to have size 0.  This is often the
case when no traceable reference to an object was found in a previous GC
pass and the memory has been reused for other purposes.

So it seems there is a vector or pseudovector of size 6 that somehow
attempts to resurrect a freed object (in the first slot). Unfortunately,
6 is the usual size for Lisp closures, so it's a very common allocation
and we can't just breakpoint based on that size alone.

Do you have a core dump, Óscar? I think we need to look at the vector
and see whether we can figure out how it was allocated or modified.

I think it's unlikely this particular vector is a closure, FWIW, because
the first slot of a closure vector is always a fixnum.

Pip