> > Can you please run x/64gx 0x3aa1ac0 so we can be sure > of this? > Sure: (gdb) x/64gx 0x3aa1ac0 0x3aa1ac0: 0x00000000098f1d0d 0x0000000000000030 0x3aa1ad0: 0x00000000098f1d65 0x0000000000000030 0x3aa1ae0: 0x00000000098f1dbd 0x0000000000000030 0x3aa1af0: 0x00000000098f1e15 0x0000000000000030 0x3aa1b00: 0x00000000098f1e6d 0x0000000000000030 0x3aa1b10: 0x00000000098f1ec5 0x0000000000000030 0x3aa1b20: 0x00000000098f1f1d 0x0000000000000030 0x3aa1b30: 0x00000000098f1f75 0x0000000000000030 0x3aa1b40: 0x00000000098f1fcd 0x0000000000000030 0x3aa1b50: 0x00000000098f2025 0x0000000000000030 0x3aa1b60: 0x00000000098f207d 0x0000000000000030 0x3aa1b70: 0x00000000098f20d5 0x0000000000000030 0x3aa1b80: 0x00000000098f212d 0x0000000000000030 0x3aa1b90: 0x00000000098f2185 0x0000000000000030 0x3aa1ba0: 0x00000000098f21dd 0x0000000000000030 0x3aa1bb0: 0x00000000098f2235 0x0000000000000030 0x3aa1bc0: 0x00000000098f228d 0x0000000000000030 0x3aa1bd0: 0x00000000098f22e5 0x0000000000000030 0x3aa1be0: 0x00000000098f233d 0x0000000000000030 0x3aa1bf0: 0x00000000098f2395 0x0000000000000030 0x3aa1c00: 0x00000000098f23ed 0x0000000000000030 0x3aa1c10: 0x00000000098f2445 0x0000000000000030 0x3aa1c20: 0x00000000098f249d 0x0000000000000030 0x3aa1c30: 0x00000000098f24f5 0x0000000000000030 0x3aa1c40: 0x00000000098f254d 0x0000000000000030 0x3aa1c50: 0x00000000098f25a5 0x0000000000000030 0x3aa1c60: 0x0000000000000007 0x0000000000000007 0x3aa1c70: 0x0000000000000007 0x0000000000000007 0x3aa1c80: 0x0000000000000007 0x0000000000000007 0x3aa1c90: 0x0000000000000007 0x0000000000000007 0x3aa1ca0: 0x0000000000000007 0x0000000000000007 0x3aa1cb0: 0x0000000000000007 0x0000000000000007 (gdb) Keep them coming! Are you still suspecting X? Thanks! George On Sat, May 17, 2025 at 5:17 PM Pip Cet wrote: > "George P" writes: > > > Can you try this (subtracting 5 from the tagged pointer to get the base > > pointer, then printing its memory region): > > > > x/32gx 0x98e79d8 > > x/32gx 0x98f1d08 > > > > (gdb) x/32gx 0x98e79d8 > > 0x98e79d8: 0xc00000000e008000 0x0000000020e10970 > > 0x98e79e8: 0x0000000003aa20d0 0x0000000003aa1ac0 > > 0x98e79f8: 0x00000000006e9960 0x000000002265f480 > > 0x98e7a08: 0x0000001a0000001a 0x0000400700000060 > > 0x98e7a18: 0x0000000000000000 0x400000000e008000 > > 0x98e7a28: 0x000000001bfdbe90 0x0000000020e10b80 > > 0x98e7a38: 0x000000001bfdb880 0x00000000006e98e0 > > 0x98e7a48: 0x000000001fd792e0 0x0000001a0000001a > > 0x98e7a58: 0x0000400700000060 0x0000000000000000 > > 0x98e7a68: 0x400000001f000005 0x0000000000000606 > > 0x98e7a78: 0x0000000008ae5654 0x000000001b78fe2d > > 0x98e7a88: 0x0000000000000012 0x0000000008ae5674 > > 0x98e7a98: 0x400000001f000005 0x0000000000000606 > > 0x98e7aa8: 0x0000000008ae5694 0x000000001c32b8dd > > 0x98e7ab8: 0x000000000000000e 0x0000000008ae5674 > > 0x98e7ac8: 0x000000000000000e 0x000015554de5d450 > > This tells us the stale pointer was most likely found in a hash table, > with 26 elements. Can you please run x/64gx 0x3aa1ac0 so we can be sure > of this? > > Unfortunately, most likely, all that is going to tell us the basic types > of the keys and values in the hash table, and we're then going to have > to investigate the surviving keys and values to get a clue as to what > the hash table might have been. Unless someone can think of a better > way? > > Thanks again! > > Pip > >