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 8:45 AM Pieter van Oostrum
> <pieter-l@vanoostrum.org> wrote:
>> Pip Cet <pipcet@gmail.com> writes:
>> > On Tue, Mar 17, 2020 at 4:54 AM Pip Cet <pipcet@gmail.com> wrote:
>> >> m has not been set; it would have been set to 0x12590f570; can you
>> >> print out the memory at that address? (x/32gx 0x12590f570)
>> >
>> > Actually, regardless of whether the pseudovector type is poisoned or
>> > zero,
>
> It's zero.
>
>> > it would be good to dump that entire vector block (x/512gx
>> > 0x12590f000)
>
>> 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.

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


>> 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?
>
>> 0x12590f540:    0x4000000003005000      0x000000015b8a3b30
>> 0x12590f550:    0xa5a5a5a5a5a5a5a4      0x000000016082a820
>> 0x12590f560:    0x0000000000014ba0      0x0000000000014ba0
>> 0x12590f570:    0x0000000000000000      0x000000015b8a3b30
>
> That's our corrupt word.
>
>> 0x12590fbf0:    0x00000001079ffc00      0x0000000000000000
>
> And that's the end of the vector block.
>
> If you want to, you can try the attached patch and see whether it
> produces anything poisoned rather than merely corrupt.
>
I'll do that after I have extracted enough information from the current setting.

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