Re: [MLton] Crash in GC

Thanks! Trying again with some more debug output, the failure is

gc.c: assertIsObjptrInFromSpace opp = 0x0000080000027308  *opp = 0x0000080000346e00

at a time when 

0x0000080000000000 - start of heap
0x00000800001da1a0 - end of old generation
0x00000800002e50d0 - start of nursery
0x00000800002e50d0 - frontier pointer in gc_state
0x00000800003f0000 - end of heap

and so the test that fails must be "p <= s->frontier" in isPointerInNursery().

The last output from gc-messages was

[GC: Finished minor Cheney-copy; copied 66,808 bytes.]
[GC: Finished gc #34; time 18 ms,]
[GC:	heap at 0x0000080000000000 of size 4,128,768 bytes (+ 32,768 bytes card/cross map),]
[GC:	with old-gen of size 1,941,920 bytes (47.0% of heap),]
[GC:	and nursery of size 1,093,424 bytes (26.5% of heap).]

Does that suggest anything obvious? I think I would have to learn more about GCs to get really into this.

I've uploaded the offending program at https://all-day-breakfast.com/m/program.sml.gz (as it's pretty much a concatenation of publicly-available code; it just isn't something currently managed in a public repo).


Chris

On Thu, 3 Nov 2022, at 01:28, Matthew Fluet wrote:
> 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
>
> _______________________________________________
> MLton-devel mailing list
> [email protected]; [email protected]
> https://lists.sourceforge.net/lists/listinfo/mlton-devel