GNU bug report logs - #57789
Emacs 28.1 clone build with native compilation crashes on s390x

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Rob Browning <rlb <at> defaultvalue.org>
Cc: 57789 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#57789: Emacs 28.1 clone build with native compilation
 crashes on s390x
Date: Sun, 18 Sep 2022 07:22:45 +0200

Rob Browning <rlb <at> defaultvalue.org> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Looking at Rob's backtrace, 
>>
>> #0  mark_object (arg=<optimized out>) at alloc.c:6809
>> #1  0x000002aa001a8ee6 in mark_objects (n=<optimized out>, obj=0x2aa00ac54a8) at alloc.c:6607
>> #2  mark_vectorlike (header=0x2aa00ac54a0) at alloc.c:6382
>> #3  0x000002aa001a8ee6 in mark_objects (n=<optimized out>, obj=0x2aa007f4ca8) at alloc.c:6607
>> #4  mark_vectorlike (header=0x2aa007f4ca0) at alloc.c:6382
>> #5  0x000002aa001a8ee6 in mark_objects (n=<optimized out>, obj=0x2aa007c3b10) at alloc.c:6607
>> #6  mark_vectorlike (header=0x2aa007c3b08) at alloc.c:6382
>> #7  0x000002aa001a7c3e in visit_static_gc_roots (visitor=...) at alloc.c:5926
>>
>> and seeing frame#7, would it be a way forward to determine which
>> staticpro (I assume it is a staticpro) that is?  Maybe that can give a
>> clue which one can then use together with a bisect, perhaps?
>
> Not completely sure I followed, but moving up to that frame and printing
> visitor didn't work: "optimized out".

Sorry, I thought another Emacs developer would chime in, when I wrote
that.

Let me try to explain what I'm after.  Frame#7, the call to
visit_static_gc_roots shows that we are at the very beginning of a GC,
recursively marking everything that we know must survice the GC.

void
visit_static_gc_roots (struct gc_root_visitor visitor)
{
  visit_buffer_root (visitor,
                     &buffer_defaults,
                     GC_ROOT_BUFFER_LOCAL_DEFAULT);
  visit_buffer_root (visitor,
                     &buffer_local_symbols,
                     GC_ROOT_BUFFER_LOCAL_NAME);

  for (int i = 0; i < ARRAYELTS (lispsym); i++)
    {
      Lisp_Object sptr = builtin_lisp_symbol (i);
      visitor.visit (&sptr, GC_ROOT_C_SYMBOL, visitor.data);
    }

  for (int i = 0; i < staticidx; i++)
    visitor.visit (staticvec[i], GC_ROOT_STATICPRO, visitor.data);
}

First interesting thing would be where in this function we are when the
crash happens.  I was assuming it is somewhere in the last for-loop, for
reasons, but that doesn't have to be the case.

If I'm right, we are currently in the process of marking Lisp objects
referenced from C variables that are known to contains Lisp objects.
Such variables are added to staticvec with a call to staticpro.  That's
what the staticpro in my last mail menat.

But let's first see where in visit_... we are.

Previous Next

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