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

From: George P <[email-masked]>
Date: Mon, 19 May 2025 11:56:02 -0400

Here they are:

(gdb)  p *(char **)0x8f68108
$1 = 0x2018b608
"/nix/store/xdxaa55akicvs3jjrr8d7nmzla4gzbyl-emacs-30.1/lib/emacs/30.1/native-lisp/30.1-1ed0c1e8/cl-print-79bf9fb1-14d0e7d5.eln"
(gdb) x/32gx 0x9e7980
0x9e7980 <pure+3086496>:        0x0000000000000000      0x0000000000000000
0x9e7990 <pure+3086512>:        0x0000000000000000      0x0000000000000000
0x9e79a0 <pure+3086528>:        0x0000000000000000      0x0000000000000000
0x9e79b0 <pure+3086544>:        0x0000000000000000      0x0000000000000000
0x9e79c0 <pure+3086560>:        0x0000000000000000      0x0000000000000000
0x9e79d0 <pure+3086576>:        0x0000000000000000      0x0000000000000000
0x9e79e0 <pure+3086592>:        0x0000000000000000      0x0000000000000000
0x9e79f0 <pure+3086608>:        0x0000000000000000      0x0000000000000000
0x9e7a00 <pure+3086624>:        0x0000000000000000      0x0000000000000000
0x9e7a10 <pure+3086640>:        0x0000000000000000      0x0000000000000000
0x9e7a20 <pure+3086656>:        0x0000000000000000      0x0000000000000000
0x9e7a30 <pure+3086672>:        0x0000000000000000      0x0000000000000000
0x9e7a40 <pure+3086688>:        0x0000000000000000      0x0000000000000000
0x9e7a50 <pure+3086704>:        0x0000000000000000      0x0000000000000000
0x9e7a60 <pure+3086720>:        0x0000000000000000      0x0000000000000000
0x9e7a70 <pure+3086736>:        0x0000000000000000      0x0000000000000000
(gdb) p *(char **)0x8ae5588

    p *(char **)0x15554ec0ff78$2 = 0x2018b6b8
"/nix/store/xdxaa55akicvs3jjrr8d7nmzla4gzbyl-emacs-30.1/share/emacs/30.1/lisp/emacs-lisp/cl-print.elc"
(gdb)     p *(char **)0x15554ec0ff98
$3 = 0x15554f56d92e "cl-print"
(gdb)     p *(char **)0x15554ec0ff78
$4 = 0x15554f56d81f "Print OBJECT on STREAM according to its type.\nOutput
is further controlled by the variables\n`cl-print-readably',
`cl-print-compiled', along with output\nvariables for the standard printing
functions.  "...
(gdb) x/32gx 0x38294c8
0x38294c8:      0xc00000001200a000      0x000015553389a350
0x38294d8:      0x0000000000020001      0x00000000088417d0
0x38294e8:      0x0000000000000000      0x0000000000000000
0x38294f8:      0x0000000000000025      0x00000000098e7985
0x3829508:      0x000000000e754ab0      0x0000000000000000
0x3829518:      0x000000001f6463e3      0x400000001200a000
0x3829528:      0x000015553389a590      0x0000000000010001
0x3829538:      0x0000000004d5eb30      0x0000000000000000
0x3829548:      0x0000000000000000      0x0000000000000026
0x3829558:      0x00000000098e7985      0x000000000e754ae0
0x3829568:      0x0000000000000000      0x000000001f646373
0x3829578:      0x400000001200a000      0x000015553389a6a0
0x3829588:      0x0000000000030003      0x000000000e754b30
0x3829598:      0x0000000000000000      0x0000000000000000
0x38295a8:      0x0000000000000027      0x00000000098e7985
0x38295b8:      0x000000001fe4ed90      0x0000000000000000
(gdb)

Thanks!
George

On Mon, May 19, 2025 at 11:44 AM Pip Cet <[email-masked]> wrote:

> "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
>
>