bug#36649: 27.0.50; pure space and pdumper

[Robert Pluim]

>>>>> 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

    Pip> Otherwise, the attached patch should produce (probably a lot of)
    Pip> information, the last lines of which would be interesting...

Since you broke Robert's Second Rule of printf debugging, I stuck an
extra 'mark ' on the front of the fprintf in 'mark_vectorlike' :-)

0x10320c9e0 nil
0x10320c9e0 nil
0x10320c9e0 nil
0x10321ab70 z-group
0x10320c9e0 nil
0x10321a6f0 x-frame-parameter
0x10320ca40 unbound
0x10321aba0 zero-width
0x10320c9e0 nil
0x10320c9e0 nil
0x10320ca40 unbound
mark 0
make[1]: *** [bootstrap-emacs.pdmp] Segmentation fault: 11
make: *** [src] Error 2