GNU bug report logs -
#78444
30.1; Crash in GC (vector_marked_p)
Previous Next
Full log
Message #35 received at 78444 <at> debbugs.gnu.org (full text, mbox):
"George P" <georgepanagopo <at> gmail.com> writes:
> 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)
That's a native comp unit's lambda_gc_guard_h, which is quite curious.
Presumably 0x98e7985 is the native comp unit and 0x8f680f4 is its file
name, so could you please run
p *(char **)0x8f68108
to retrieve it, as well as
x/32gx 0x9e7980
to confirm it is (or was) a native comp unit?
Going back through the last_marked array, it seems we're looking at the
'function-history plist property of a symbol at 0x15554df1a3a0, but I'm
not sure which of the strings we mark after that is its name. Best to
print all of them:
p *(char **)0x8ae5588
p *(char **)0x15554ec0ff98
p *(char **)0x15554ec0ff78
The last vector or pseudovector we marked before that was 0x38294cd, so
I think we should look at
x/32gx 0x38294c8
too.
> Keep them coming! Are you still suspecting X?
Currently, it seems more likely to involve the nativecomp code, but I've
stared at it for a while and I don't see how it can resurrect comp units
once they become unreachable.
Thanks again!
Pip
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.