Re: [scratch/igc] 985247b6bee crash on Linux, KDE, Wayland

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Eval EXEC <execvy@gmail.com>
>> Cc: pipcet@protonmail.com,  gerd.moellmann@gmail.com,  emacs-devel@gnu.org
>> Date: Fri, 06 Sep 2024 11:10:15 +0800
>>
>> Eval EXEC <execvy@gmail.com> writes:
>>
>> > I recompiled commit 95a30325a84 (HEAD -> scratch/igc, origin/scratch/igc)
>> > * src/igc.c (fix_frame): Correct the previous change.
>> >
>> > After testing, I believe the issue has been resolved.
>>
>> scratch/igc 95a30325 crash again:
>>
>> I use latest scratch/igc commit: * 95a30325a84 - (HEAD -> scratch/igc, 
>> origin/scratch/igc) * src/igc.c (fix_frame): Fix last change. (8 hours ago) 
>> <Eli Zaretskii>
>>
>> #5  igc_assert_fail (file=<optimized out>, line=<optimized out>, 
>> msg=<optimized out>) at 
>> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/igc.c:209
>
> It's an assertion violation, and it's too bad 'msg' is "optimized
> out", because it's valuable information.

I suspect it's this assertion in buffer.c:

Res BufferFill(Addr *pReturn, Buffer buffer, Size size)
{
  Res res;
  Pool pool;
  Addr base, limit, next;

  AVER(pReturn != NULL);
  AVERT(Buffer, buffer);
  AVER(size > 0); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  AVER(SizeIsAligned(size, BufferPool(buffer)->alignment));
  AVER(BufferIsReady(buffer));

This happens if we try to skip over an object that has been zeroed
(because it was freed or has moved): we report a size of zero to
amcSegFix(), and the assertion violation happens because it checks that
size is greater than zero.  Maybe it's possible to die sooner than that,
in the skip method itself.

> This is a different problem, I think.

I agree.

>   {
>     MPS_SCAN_BEGIN (ss)
>     {
>       mps_word_t *p = (mps_word_t *) pobj;
>       mps_word_t word = *p;
>
>       /* Quickly rule out Qnil, and prevent subtraxting from a
>        null pointer.  */
>       if (word == 0)
>       return MPS_RES_OK;
>
>       mps_word_t tag = word & IGC_TAG_MASK;
>       if (tag == Lisp_Int0 || tag == Lisp_Int1)
>       return MPS_RES_OK;
>       else if (tag == Lisp_Type_Unused0)
>       emacs_abort ();
>
>       if (tag == Lisp_Symbol)
>       {
>         ptrdiff_t off = word ^ tag;
>         mps_addr_t client = (mps_addr_t) ((char *) lispsym + off);
>         mps_addr_t base = client;
>         if (MPS_FIX1 (ss, base))
>           {
>             mps_res_t res = MPS_FIX2 (ss, &base); <<<<<<<<<<<<<<<<<<<
>
> I guess it would be interesting to see what was the cons and what was
> the symbol that was its car?

Something related to fonts, maybe?  Those use symbols which are
allocated dynamically and may have moved:


  for (i = 0; i < fontset->nfont; i++)
    {
      FcPattern *pat = fontset->fonts[i];
      FcChar8 *str;

      if (FcPatternGetString (pat, FC_FAMILY, 0, &str) == FcResultMatch)
        list = Fcons (intern ((char *) str), list);
    }

for example, in ftfont_list_family, builds such a list.

> Like this:
>
>   (gdb) frame 9
>   (gdb) p *pobj
>   (gdb) xtype
>   (gdb) xsymbol
>   (gdb) frame 10
>   (gdb) p *cons
>   (gdb) xcons
>   (gdb) p *xcons
>   (gdb) xcdr
>   (gdb) xtype

That information would be very interesting!

Pip