GNU bug report logs - #36649
27.0.50; pure space and pdumper

Previous Next

Package: emacs;

Reported by: Pip Cet <pipcet <at> gmail.com>

Date: Sun, 14 Jul 2019 14:27:01 UTC

Severity: wishlist

Tags: patch

Found in version 27.0.50

Done: Pip Cet <pipcet <at> protonmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 36649 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: bug#36649: 27.0.50; pure space and pdumper
Date: Sun, 21 Jul 2019 19:35:01 +0000
[Message part 1 (text/plain, inline)]
On Sun, Jul 21, 2019 at 7:12 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> >>>>> On Sun, 21 Jul 2019 18:07:43 +0000, Pip Cet <pipcet <at> 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?
[0001-Initialize-the-zero-vector-properly.patch (text/x-patch, attachment)]

This bug report was last modified 199 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.