bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects

[Pip Cet]

On Fri, May 29, 2020 at 10:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Fri, 29 May 2020 10:34:20 +0000
> > Cc: Paul Eggert <eggert@cs.ucla.edu>, Stefan Monnier 
> > <monnier@iro.umontreal.ca>, 41321@debbugs.gnu.org
> >
> > > . There's nothing wrong with GDB's xtype command: it fails when a Lisp
> > >   object encodes a pointer to invalid memory:
> >
> > (gdb) p last_marked[497]
> > $100 = XIL(0x439c370)
> > (gdb) xtype
> > Lisp_Vectorlike
> > Cannot access memory at address 0x1ffac2a8
> >
> > Again, that can't be right. $100 is a Lisp_Symbol, not a vectorlike,
> > and it's not at address 0x1ffac2a8.
> >
> > So my suspicion remains that this is a gdb bug, and it appears to be a
> > reproducible one!
>
> There's no bug:

I believe there is.

> the $size variable was not updated inside pvectype
> because the 'set' command tried to access invalid memory.

Why would pvectype be called at all? xtype should have said
"Lisp_Symbol", not "Lisp_Vectorlike", and never gotten to pvectype at
all.

Feel free to try that, in a fresh GDB session:

p 0x439c370
xtype

> So the rest
> is using the stale value of $size.  Puff! no miracle and no bug.

Which rest? There's no message after "Cannot access memory at address
0x1ffac2a8"

> You just don't need to assign too much importance to the address the
> error message displays, it might not be the problematic address.

Or there might not be a problematic address, because xtype is somehow
using the value of $ which it used when it encountered the initial bug
even for subsequent calls. It doesn't do that here.