On Tue, Mar 17, 2020 at 8:45 AM Pieter van Oostrum wrote: > Pip Cet writes: > > On Tue, Mar 17, 2020 at 4:54 AM Pip Cet 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? > 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) > 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?) > 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. Thanks again!