Re: [MLton] Crash in GC

--===============7124389251429421851==
Content-Type: multipart/alternative; boundary="00000000000009ad5c05ec86e26b"

--00000000000009ad5c05ec86e26b
Content-Type: text/plain; charset="UTF-8"

Agreed that, while non-default, your GC options aren't particularly unusual
and there is a true GC bug there.

You can automate compiling with `-g` and linking to the debug runtime by
compiling with `-debug true`.

The https://github.com/MLton/mlton/blob/master/runtime/gc/debug.h has a
number of enums/constants that can be switched from `FALSE` to `TRUE` to
turn on additional assertions and logging.  `DEBUG_GENERATIONAL` would seem
to be a good candidate to enable.  It can also be helpful to simply run the
program with `@MLton gc-messages`, which will print out information at the
start and end of each GC, especially about the address and sizes of the
heaps (including generational boundary).  That might help to understand if
the bad pointer is "near" the FromSpace or in an old heap or something
similar.

Feel free to follow up with more information or to share the bug-triggering
program if its still hard to track down.

-Matthew

On Wed, Nov 2, 2022 at 11:58 AM Chris Cannam <[email protected]>
wrote:

> Hello!
>
> I have a pure SML program (no FFI) which compiles and runs when compiled
> with the default MLton options, but crashes with a segfault when compiled
> with certain GC flags.
>
> For example,
>
> $ mlton program.sml
> $ ./program
>
> runs to completion, while
>
> $ mlton -runtime 'copy-generational-ratio 10.0' program.sml
> $ ./program
>
> runs for a second or so and then crashes. The crash is a segfault in
> (according to gdb) forwardObjptr within performGC.
>
> I tried emitting C and compiling that with -g linked against
> libmlton-dbg.a, and in this mode I get an assertion failure::
>
> gc/invariant.c:13:
> assertIsObjptrInFromSpaceOrImmutableMutableOrRootStaticHeap: Assertion
> `isObjptrInFromSpace (s, *opp) ||
> isObjptrInImmutableMutableOrRootStaticHeap (s, *opp)' failed.
>
> The failure is within the invariant check made at the end of performGC
> just before leaveGC is called, and is within the "checking old generation"
> part of invariantForGC.
>
> The same behaviour happens with the Arch Linux package of 20210117 and
> with a clean build from the current MLton repo, and it doesn't appear to
> matter which codegen I use.
>
> Any tips or ideas for how to debug this? Besides that it seems a bug, I am
> afraid that a failure in GC with unusual options now has the potential to
> become a failure with default options in the future under different memory
> pressure or allocation patterns.
>
> I can provide a test program off-list if that would help anyone get to
> grips with it, but although it's just a single SML file, it is quite large
> - the result of concatenating about 38k lines from other files - and I
> haven't identified a nice small test case.
>
>
> Chris
>
>
> _______________________________________________
> MLton-devel mailing list
> [email protected]; [email protected]
> https://lists.sourceforge.net/lists/listinfo/mlton-devel
>

--00000000000009ad5c05ec86e26b
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">Agreed that, while non-default, your GC options a=
ren&#39;t particularly unusual and there is a true GC bug there.</div><div =
class=3D"gmail_default" style=3D"font-family:arial,sans-serif;font-size:lar=
ge"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,sans-=
serif;font-size:large">You can automate compiling with `-g` and linking to =
the debug runtime by compiling with `-debug true`.<br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,sans-serif;font-size:large"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,sans-serif;font=
-size:large">The <a href=3D"https://github.com/MLton/mlton/blob/master/runt=
ime/gc/debug.h">https://github.com/MLton/mlton/blob/master/runtime/gc/debug=
.h</a> has a number of enums/constants that can be switched from `FALSE` to=
 `TRUE` to turn on additional assertions and logging.=C2=A0 `DEBUG_GENERATI=
ONAL` would seem to be a good candidate to enable.=C2=A0 It can also be hel=
pful to simply run the program with `@MLton gc-messages`, which will print =
out information at the start and end of each GC, especially about the addre=
ss and sizes of the heaps (including generational boundary).=C2=A0 That mig=
ht help to understand if the bad pointer is &quot;near&quot; the FromSpace =
or in an old heap or something similar.</div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,sans-serif;font-size:large"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,sans-serif;font-size:large">F=
eel free to follow up with more information or to share the bug-triggering =
program if its still hard to track down.</div><div class=3D"gmail_default" =
style=3D"font-family:arial,sans-serif;font-size:large"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,sans-serif;font-size:large">-=
Matthew<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Wed, Nov 2, 2022 at 11:58 AM Chris Cannam &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!=
<br>
<br>
I have a pure SML program (no FFI) which compiles and runs when compiled wi=
th the default MLton options, but crashes with a segfault when compiled wit=
h certain GC flags.<br>
<br>
For example,<br>
<br>
$ mlton program.sml<br>
$ ./program<br>
<br>
runs to completion, while<br>
<br>
$ mlton -runtime &#39;copy-generational-ratio 10.0&#39; program.sml<br>
$ ./program<br>
<br>
runs for a second or so and then crashes. The crash is a segfault in (accor=
ding to gdb) forwardObjptr within performGC.<br>
<br>
I tried emitting C and compiling that with -g linked against libmlton-dbg.a=
, and in this mode I get an assertion failure::<br>
<br>
gc/invariant.c:13: assertIsObjptrInFromSpaceOrImmutableMutableOrRootStaticH=
eap: Assertion `isObjptrInFromSpace (s, *opp) || isObjptrInImmutableMutable=
OrRootStaticHeap (s, *opp)&#39; failed.<br>
<br>
The failure is within the invariant check made at the end of performGC just=
 before leaveGC is called, and is within the &quot;checking old generation&=
quot; part of invariantForGC.<br>
<br>
The same behaviour happens with the Arch Linux package of 20210117 and with=
 a clean build from the current MLton repo, and it doesn&#39;t appear to ma=
tter which codegen I use.<br>
<br>
Any tips or ideas for how to debug this? Besides that it seems a bug, I am =
afraid that a failure in GC with unusual options now has the potential to b=
ecome a failure with default options in the future under different memory p=
ressure or allocation patterns.<br>
<br>
I can provide a test program off-list if that would help anyone get to grip=
s with it, but although it&#39;s just a single SML file, it is quite large =
- the result of concatenating about 38k lines from other files - and I have=
n&#39;t identified a nice small test case.<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>

--00000000000009ad5c05ec86e26b--


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


--===============7124389251429421851==
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

--===============7124389251429421851==--