On Wed, Jun 21, 2023 at 10:07:34PM +0000, GitLab wrote: > GitLab > ✖ Pipeline #907639365 has failed! > > Project nbdkit / nbdkit > Branch ● master > Commit ● 9d4b87e0 > ocaml: Fix thread registration for OCaml 5 OCa... > Commit Author ● Richard W.M. Jones > > Pipeline #907639365 triggered by ● Richard W.M. Jones > had 9 failed jobs > Failed jobs > ✖ builds x86_64-fedora-rawhide-clang-prebuilt-env > ✖ builds x86_64-almalinux-8-clang-prebuilt-env > ✖ builds x86_64-almalinux-8-prebuilt-env > ✖ builds aarch64-macos-12 > ✖ builds x86_64-centos-stream-8-prebuilt-env > ✖ builds x86_64-debian-11-prebuilt-env > ✖ builds x86_64-debian-sid-prebuilt-env > ✖ builds x86_64-fedora-rawhide-prebuilt-env > ✖ builds x86_64-fedora-36-prebuilt-env Some of these tests are failing in: tests/test-shebang-cc-ocaml.sh tests/test-cc-ocaml.sh after the OCaml changes I pushed yesterday, and yes this does appear to be a genuine problem, but I'm not sure why it happens or how to fix it. It seems as if the OCaml runtime gets confused after nbdkit forks, which manifests as a hang here: https://gitlab.com/nbdkit/nbdkit/-/blob/3e4c1b79a72970c17cb42b21070e61ec6... OCaml has a mechanism for registering an atfork handler which is supposed to reinitialize the thread state, but for some reason that doesn't work or isn't getting called. Also this mechanism hasn't changed much in OCaml 5, yet the tests appear to work there (although it could also be that the mechanism or test is racy, and I only have one machine with OCaml 5 installed). Anyway, I will poke again at this later.