I observed a segmentation fault with OCaml 5.0 (alpha0, alpha1 and ocaml/opam:debian-11-ocaml-5.0 docker image), which can be reproduced with the following steps. The same steps do not trigger segmentation fault with OCaml 4.14 and below (but the problem looks such fragile with respect to any change that I am not sure it is related to OCaml 5.0).

$ docker run -it --rm ocaml/opam:debian-11-ocaml-5.0
opam@...:~$ opam pin add https://github.com/thierry-martinez/stdcompat.git#disable-magic
opam@...:~$ opam pin add https://github.com/thierry-martinez/metapp.git
opam@...:~$ opam pin add https://github.com/thierry-martinez/metaquot.git#ocaml-5.0-segfault
opam@...:~$ opam install refl

I wish I would be able to make a more standalone and small example, to be sure that the fault is not in my code, but I am stuck in how I can reduce it without making the segmentation fault disappears. I already asked for help on discuss.ocaml.org and @lthls commented:

I’ve started debugging the issue, and it looks like there is a big closure allocation (size 552, start of environment at 527) that is being initialized, and the GC is running in the middle of the initialization. Because the block is not initialized yet, the start_of_env field is not yet set properly, so the block is pushed on the mark stack with offset 0 (i.e. not skipping code pointers). After a bit of marking, the block is put back on the mark stack with a non-zero offset, and execution resumes. The initialization code finishes running, and when marking resumes it starts trying to mark code pointers. This is what triggers the segfault. I haven’t found yet why the GC manages to run between the initial allocation and its initialization though: the window is very short, and doesn’t contain any code that looks likely to trigger a GC. Hopefully someone more familiar than me about the GC will find the answer.

Sorry for such a non minimal example, and thank you very much!