bug#39962: 27.0.90; Crash in Emacs 27.0.90

[Pieter van Oostrum]

Pip Cet <pipcet@gmail.com> writes:

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

(gdb) xprintsym 0xd4269c0
Invalid number "0xd4269c0.i".
(gdb) pp 0xd4269c0
Invalid cast.

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

(gdb) x/32gx 0xd4269c0
0xd4269c0:      Cannot access memory at address 0xd4269c0


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

(gdb) x/32gx 0x5757688
0x5757688:      Cannot access memory at address 0x5757688

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

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]