Eli Zaretskii <eliz@gnu.org> writes:

> On January 9, 2020 9:51:43 AM GMT+02:00, Robert Pluim <rpluim@gmail.com> wrote:
>> <rpluim@gmail.com> said:
>>> As another data point, Iʼm writing this from an emacs with 'ok
>>> = true', which has not crashed yet....
>> 
>> scratch that, it crashed this morning.
>> 
>> Robert
>
> Thanks for trying.
>
> A stab in the dark: does it help to rename the variable 'ok' in
> face_inherited_attr to some other name, like 'ok1'?
>
> Also, can I please see one backtrace with all the call-stack frames,
> starting from 'main' and ending at 'handle_fatal_signal'?  The
> original report shows only the top-most 511 frames, and the other one
> has a lot of ?? (missing symbols) in it.
>
> And finally, are all the crashes inside GC, or do some happen outside
> it?

I made an assumption that gdb is indeed working incorrectly for me
because:
- It can't print last_marked
- It shows a lot of ?? in call-stack
- Emacs is not crashing if running not under gdb
- Emacs keep working after continuing execution after gdb reaches
  terminate_due_to_signal breakpoint

So I tried to use lldb.
Under lldb the crash is not occured on commit with 'ok = false'.

Also I came up with code to reproduce crash under 'emacs -Q' at least on
my machine.

Here is the '~/emacs-crash.el' content:
(make-frame `((parent-frame . ,(window-frame))))
(make-frame `((parent-frame . ,(window-frame))))
(make-frame `((parent-frame . ,(window-frame))))
(make-frame `((parent-frame . ,(window-frame))))
(delete-frame)
(delete-frame)
(delete-frame)
(delete-frame)
(garbage-collect)

This code is start crashing on the commit
bb42f6ef10cb250a9263b17a8794e950a563d5d0

Though I can't use xTYPE commands under lldb please see attached lldb
output. It has all the call-stack frames starting from 'main'.