bug#38748: 28.0.50; crash on MacOS 10.15.2

[Robert Pluim]

>>>>> On Thu, 02 Jan 2020 16:06:23 +0200, Eli Zaretskii <eliz@gnu.org> said:

Iʼm now seeing this as well on both master and emacs-27

    Eli> This looks like some compiler bug, or maybe bug in GDB on your
    Eli> platform?  Because the source clearly says

    Eli>    Lisp_Object last_marked[LAST_MARKED_SIZE] EXTERNALLY_VISIBLE;

    Eli> so the type should be known to GDB.  But this is just an aside.

    >> But I found the commit after which error is occurs:
    >> b2949d39261e82c33572ba8a250298ef0b165b95
    >> 
    >> Commenting out that 'ok = false;' line make Emacs works without errors.

I can confirm this.

    Eli> I cannot explain how that change could cause any harm.  Here's the
    Eli> relevant code fragment:

    Eli>       if (CONSP (parent_face))
    Eli>        {
    Eli>          Lisp_Object tail;
    Eli>          ok = false;
    Eli>          for (tail = parent_face; !NILP (tail); tail = XCDR (tail))
    Eli>            {
    Eli>              ok = get_lface_attributes (w, f, XCAR (tail), 
inherited_attrs,
    Eli>                                         false, named_merge_points);
    Eli>              if (!ok)
    Eli>                break;
    Eli>              attr_val = face_inherited_attr (w, f, inherited_attrs, 
attr_idx,
    Eli>                                              named_merge_points);
    Eli>              if (!UNSPECIFIEDP (attr_val))
    Eli>                break;
    Eli>            }
    Eli>          if (!ok)      /* bad face? */
    Eli>            break;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Eli>        }
    Eli>       else
    Eli>        {
    Eli>          ok = get_lface_attributes (w, f, parent_face, inherited_attrs,
    Eli>                                     false, named_merge_points);
    Eli>          if (!ok)
    Eli>            break;
    Eli>          attr_val = inherited_attrs[attr_idx];
    Eli>        }

    Eli> Since parent_face is a cons cell, then we enter the for-loop (since a
    Eli> cons cell cannot be nil), and then we immediately call
    Eli> get_lface_attributes whose return value overwrites the initial value
    Eli> of 'ok'.

    Eli> So how could the initial value of 'ok' matter here?  What am I
    Eli> missing?

    Eli> Can you run the unmodified code with a breakpoint on the line
    Eli> indicated by "<<<<<" above, and see if the breakpoint ever breaks?  If
    Eli> it does break, can you show the face being merged in this case?

It never breaks there for me.

    Eli> Also, if you build Emacs with exactly the same configure options, but
    Eli> without optimizations, does the problem persist?

Yes. Iʼll note that when this happens there are over 9000 stackframes,
so perhaps itʼs stack exhaustion. macOS has a default stack of 8192
kB, Iʼll see if increasing it helps.

Iʼm running under lldb as well, perhaps that will work better with
'last_marked'.

Robert