bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pip Cet]

On Tue, Mar 17, 2020 at 3:27 PM Pieter van Oostrum
<pieter-l@vanoostrum.org> wrote:
> Pip Cet <pipcet@gmail.com> writes:
> > On Tue, Mar 17, 2020 at 8:45 AM Pieter van Oostrum
> > <pieter-l@vanoostrum.org> wrote:
> >> 0x12590f3f0:    0x0000000000000006      0x0000000000000000
> >> 0x12590f400:    0x000000000d4269c0      0x0000000000000000
> >
> > I'm suspicious about this "symbol". Is 0xd4269c0 a valid lisp value?
>
> I'm sorry. I don't know how to find out. I'm just a newbee with debugging 
> elisp in gdb.

I believe "xprintsym 0xd4269c0" would work on macOS, too. I'm not sure
whether "pp 0xd4269c0" would.

"x/32gx 0xd4269c0" would also be interesting, potentially, if that is
a valid memory address.

> >> 0x12590f430:    0x0000000000000002      0x0000000000008df0
> >> 0x12590f440:    0x0000000005757688      0xa5a5a5a5a5a5a5a5
> >
> > This vector is weird. The first entry is a symbol, but the second
> > entry looks invalid to me: all other symbols are aligned to 16-byte
> > boundaries, and I don't think 0x5757688 is even a valid pointer.

"x/32gx 0x5757688" would also be interesting if it works.

> > Can you check which symbol corresponds to 0x8df0 in your build? It
> > should be the one with 757 in its define line in globals.h
> >
> > # define Qlibpng_version builtin_lisp_symbol (757)
>
> Sorry, again, I don't know how to find that symbol. I guess it's one of the 
> functions defined in .gdbinit, but I don't know which one.
>
> And in globals.h, the numbers are different.
>
> # define Qlibpng_version builtin_lisp_symbol (687)
> # define Qmode_line builtin_lisp_symbol (757)

Thanks, that's precisely what I wanted to know. So it's a vector
[mode-line X], where X is either a very peculiar symbol or invalid.

> >> 0x12590f520:    0x4000000002002000      0x0000000200000003
> >> 0x12590f530:    0x000000011de53fc0      0xa5a5a5a5a5a5a5a5
> >
> > A real-life bignum! Can you print x/2gx 0x11de53fc0 so we figure out
> > what its value is? (And what's creating bignums in your session?)
>
> (gdb) x/2gx 0x11de53fc0
> 0x11de53fc0:    0xe3fedf0cbab410c0      0x0000000000000055
>
> I don't think there is something explicitely creating bignums. But could it 
> be the result of a calculation that doesn't fit in an normal int?

It's a picosecond time stamp, so that's okay.