Re: [MLton] Crash in GC

--===============3753735141263845329==
Content-Type: multipart/alternative; boundary="000000000000443ab205eccf4aa9"

--000000000000443ab205eccf4aa9
Content-Type: text/plain; charset="UTF-8"

Definitely looks like a problem with card marking.  What's surprising is
that that is a very simple operation; anytime there is a write of a object
pointer into the field of an object (as induced by either `Array.update` or
reference `:=`), we simply write TRUE into the card for the address of the
written-to object divided by 256.  See:

https://github.com/MLton/mlton/blob/master/mlton/backend/ssa2-to-rssa.fun#L638

https://github.com/MLton/mlton/blob/master/mlton/backend/ssa2-to-rssa.fun#L945
If the address of the bad intergenerational pointer is consistent between
runs, then I would run the program under gdb until the end of the last
successful GC, then set a hardware watchpoint on the address that will be
written with the pointer into the nursery and then look at the C/assembly
that immediately follows the write; that should mark a corresponding card.


On Sun, Nov 6, 2022 at 10:03 AM Chris Cannam <[email protected]>
wrote:

> Thanks for the clear explanation!
>
> On Sun, 6 Nov 2022, at 02:43, Matthew Fluet wrote:
> > We should be checking that intergenerational pointers have their
> > corresponding card marked, but that test is currently disabled:
> > https://github.com/MLton/mlton/blob/master/runtime/gc/invariant.c#L23
> > I'm guessing that if we enabled/fixed that, then we would trip the
> > invariant at the beginning of the GC
>
> Indeed it does - I enabled that (but made it non-fatal because of the
> warning about false positives) and it logs
>
> gc.c: intergenerational pointer from 0x0000080000027308 to
> 0x0000080000346e00 with unmarked card.
>
> after the starting GC messages. It's not the only one in this GC either -
> there are 9 of them - though again I see the caveat about false positives
> in the comment.
>
>
> Chris
>
>
> _______________________________________________
> MLton-devel mailing list
> [email protected]; [email protected]
> https://lists.sourceforge.net/lists/listinfo/mlton-devel
>

--000000000000443ab205eccf4aa9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,sa=
ns-serif;font-size:large">Definitely looks like a problem with card marking=
.=C2=A0 What&#39;s surprising is that that is a very simple operation; anyt=
ime there is a write of a object pointer into the field of an object (as in=
duced by either `Array.update` or reference `:=3D`), we simply write TRUE i=
nto the card for the address of the written-to object divided by 256.=C2=A0=
 See:</div><div class=3D"gmail_default" style=3D"font-family:arial,sans-ser=
if;font-size:large">=C2=A0 <a href=3D"https://github.com/MLton/mlton/blob/m=
aster/mlton/backend/ssa2-to-rssa.fun#L638">https://github.com/MLton/mlton/b=
lob/master/mlton/backend/ssa2-to-rssa.fun#L638</a></div><div class=3D"gmail=
_default" style=3D"font-family:arial,sans-serif;font-size:large">=C2=A0 <a =
href=3D"https://github.com/MLton/mlton/blob/master/mlton/backend/ssa2-to-rs=
sa.fun#L945">https://github.com/MLton/mlton/blob/master/mlton/backend/ssa2-=
to-rssa.fun#L945</a></div><div class=3D"gmail_default" style=3D"font-family=
:arial,sans-serif;font-size:large">If the address of the bad intergeneratio=
nal pointer is consistent between runs, then I would run the program under =
gdb until the end of the last successful GC, then set a hardware watchpoint=
 on the address that will be written with the pointer into the nursery and =
then look at the C/assembly that immediately follows the write; that should=
 mark a corresponding card.</div><div class=3D"gmail_default" style=3D"font=
-family:arial,sans-serif;font-size:large"><br></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Nov 6, 2022 at =
10:03 AM Chris Cannam &lt;<a href=3D"mailto:[email protected]">c=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">Thanks for the clear explanation!<br>
<br>
On Sun, 6 Nov 2022, at 02:43, Matthew Fluet wrote:<br>
&gt; We should be checking that intergenerational pointers have their <br>
&gt; corresponding card marked, but that test is currently disabled:<br>
&gt; <a href=3D"https://github.com/MLton/mlton/blob/master/runtime/gc/invar=
iant.c#L23" rel=3D"noreferrer" target=3D"_blank">https://github.com/MLton/m=
lton/blob/master/runtime/gc/invariant.c#L23</a><br>
&gt; I&#39;m guessing that if we enabled/fixed that, then we would trip the=
 <br>
&gt; invariant at the beginning of the GC<br>
<br>
Indeed it does - I enabled that (but made it non-fatal because of the warni=
ng about false positives) and it logs<br>
<br>
gc.c: intergenerational pointer from 0x0000080000027308 to 0x0000080000346e=
00 with unmarked card.<br>
<br>
after the starting GC messages. It&#39;s not the only one in this GC either=
 - there are 9 of them - though again I see the caveat about false positive=
s in the comment.<br>
<br>
<br>
Chris<br>
<br>
<br>
_______________________________________________<br>
MLton-devel mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">MLto=
[email protected]</a>; <a href=3D"mailto:[email protected]"=
 target=3D"_blank">[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/mlton-devel" rel=3D=
"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo=
/mlton-devel</a><br>
</blockquote></div>

--000000000000443ab205eccf4aa9--


--===============3753735141263845329==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============3753735141263845329==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
MLton-devel mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-devel

--===============3753735141263845329==--