bug#38748: 28.0.50; crash on MacOS 10.15.2

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> Cc: alan@idiocy.org,  38748@debbugs.gnu.org,  jguenther@gmail.com
> Date: Wed, 01 Jan 2020 22:42:19 +0200
> 
> >   (gdb) p last_marked_index
> >   $2 = 1
> >   (gdb) p last_marked[0]
> >   $3 = XIL(0x8000000006287630)
> >   (gdb) xtype
> >   Lisp_String
> >   (gdb) xstring
> >   $4 = (struct Lisp_String *) 0x6287630
> >   " *buffer-defaults*"
> 
> I'm still have no luck to print last_marked item:
> 
> (gdb) p last_marked_index
> $1 = 278
> (gdb) p last_marked[277]
> 'last_marked' has unknown type; cast it to its declared type

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

   Lisp_Object last_marked[LAST_MARKED_SIZE] EXTERNALLY_VISIBLE;

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 cannot explain how that change could cause any harm.  Here's the
relevant code fragment:

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

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

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

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

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

Thanks.