On Sun, Jul 21, 2019 at 7:12 PM Robert Pluim <rpluim@gmail.com> wrote:
> >>>>> On Sun, 21 Jul 2019 18:07:43 +0000, Pip Cet <pipcet@gmail.com> said:
>     Pip> I'm not sure about debugging on macOS, but can you get a full
>     Pip> backtrace, or a core dump, or both? We're particularly interested in
>     Pip> what "i" is in mark_vectorlike.
>
> You want a lisp backtrace? I can always run under gdb if needed. As to
> 'i':
>
> (lldb) up
> frame #1: 0x000000010016dbec temacs`mark_object(arg=<unavailable>) at alloc.c:6082 [opt]
>    6079       {
>    6080         struct Lisp_Symbol *ptr = XSYMBOL (obj);
>    6081       nextsym:
> -> 6082         if (symbol_marked_p (ptr))
>    6083           break;
>    6084         CHECK_ALLOCATED_AND_LIVE_SYMBOL ();
>    6085         set_symbol_marked(ptr);
> (lldb)
> frame #2: 0x000000010016f2aa temacs`mark_vectorlike(header=0x0000000101803200) at alloc.c:5666:5 [opt]
>    5663      The distinction is used e.g. by Lisp_Process which places extra
>    5664      non-Lisp_Object fields at the end of the structure...  */
>    5665   for (i = 0; i < size; i++) /* ...and then mark its elements.  */
> -> 5666     mark_object (ptr->contents[i]);
>    5667 }
>    5668
>    5669 /* Like mark_vectorlike but optimized for char-tables (and
> (lldb) p i
> (ptrdiff_t) $0 = 0
> (lldb) p ptr->contents
> error: incomplete type 'Lisp_Object []' where a complete type is required
> (lldb) p ptr->contents[0]
> (Lisp_Object) $1 = 0x0008040000080400

Thanks! I messed up quite badly initializing the zero vector, it turns
out, so it was trying to initialize the first entry in the zero
vector, which, er, obviously wasn't a good idea :-)

Can you try again with this incremental patch?