[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38748: 28.0.50; crash on MacOS 10.15.2
From: |
Robert Pluim |
Subject: |
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@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
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Andrii Kolomoiets, 2020/01/01
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Eli Zaretskii, 2020/01/02
- bug#38748: 28.0.50; crash on MacOS 10.15.2,
Robert Pluim <=
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Pip Cet, 2020/01/08
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Eli Zaretskii, 2020/01/08
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Pip Cet, 2020/01/08
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Eli Zaretskii, 2020/01/08
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Pip Cet, 2020/01/10
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Eli Zaretskii, 2020/01/10
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Robert Pluim, 2020/01/10
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Eli Zaretskii, 2020/01/10
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Robert Pluim, 2020/01/10
- bug#38748: 28.0.50; crash on MacOS 10.15.2, Pankaj Jangid, 2020/01/11