bug#36649: 27.0.50; pure space and pdumper

[Robert Pluim <rpluim@gmail.com>]

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