GNU bug report logs - #38748
28.0.50; crash on MacOS 10.15.2

Previous Next

Full log

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alan <at> idiocy.org, jguenther <at> gmail.com,
 Andrii Kolomoiets <andreyk.mad <at> gmail.com>, 38748 <at> debbugs.gnu.org
Subject: Re: bug#38748: 28.0.50; crash on MacOS 10.15.2
Date: Wed, 08 Jan 2020 18:39:42 +0100

>>>>> On Thu, 02 Jan 2020 16:06:23 +0200, Eli Zaretskii <eliz <at> 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

Previous Next

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