Subject: Re: bug#78444: 30.1; Crash in GC (vector_marked_p)

From: Pip Cet <[email-masked]>
Date: Mon, 19 May 2025 15:44:00 +0000

"George P" <[email-masked]> 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