[ocaml5-issue] Abort on Lin DSL Ephemeron test under debug runtime

[jmid]

I just spotted this in the CI logs after merging the Lockfree-removal PR.

The Lin DSL Ephemeron test aborts on Linux 5.0.0 when run under the debug runtime:
https://github.com/ocaml-multicore/multicoretests/actions/runs/3747248572/jobs/6363293260

random seed: 479273929
generated error fail pass / total     time test name

[ ]    0    0    0    0 / 1000     0.0s Lin DSL Ephemeron test with Domain
[ ]    0    0    0    0 / 1000     0.0s Lin DSL Ephemeron test with Domain (generating)
[00] file runtime/shared_heap.c; line 807 ### Assertion failed: hd == 0 || !Has_status_hd(hd, caml_global_heap_state.GARBAGE)
File "src/ephemeron/dune", line 13, characters 7-20:
13 |  (name lin_tests_dsl)
            ^^^^^^^^^^^^^
(cd _build/default/src/ephemeron && ./lin_tests_dsl.exe --verbose)
Command got signal ABRT.
[ ]    5    0    0    5 / 1000    61.1s Lin DSL Ephemeron test with Domain (shrinking:    6.0002)

[jmid]

I found another occurrence of this on main - again while testing Linux 5.0.0 debug:
https://github.com/ocaml-multicore/multicoretests/actions/runs/4494673332/jobs/7907445766

random seed: 470367559
generated error fail pass / total     time test name

[ ]    0    0    0    0 / 1000     0.0s Lin DSL Ephemeron test with Domain
[02] file runtime/domain.c; line 992 ### Assertion failed: di->backup_thread_msg == BT_INIT || di->backup_thread_msg == BT_TERMINATE
File "src/ephemeron/dune", line 13, characters 7-20:
13 |  (name lin_tests_dsl)
            ^^^^^^^^^^^^^
(cd _build/default/src/ephemeron && ./lin_tests_dsl.exe --verbose)
Command got signal ABRT.
[ ]    0    0    0    0 / 1000     0.0s Lin DSL Ephemeron test with Domain (generating)

It may be fixed on trunk though (I don't recall seeing this failure there).

[jmid]

The second failure looks much more like #402 which is now fixed.
The former failure we haven't seen since - partly because the Lin DSL Ephemeron test was removed ~6 months later as part of #367 to make Ephemeron test outcomes more reliable.
I'll therefore close this. We can reopen if the assertion failure shows up again.