Is there a similar issue in caml_ml_set_channel_name, since Lock(channel) involves a blocking section?

Note that the bug was already a bug in OCaml 4; your explanation is in terms of domains but (non-parallel) threads can create the same problems.

Random remark: another way to keep a channel alive is to increase its refcount before and decrement it after the work has been done. I think that simply registering the root as proposed is a much better approach, of course.

As @yallop I started looking for other instances of related bugs in io.c. I suspect that there may be several others, for example:

• caml_channel_size looks suspicious to me: we use the file descriptor within the critical section, which could have been closed by a finalizer at this point
• caml_ml_set_channel_name is wrong as @yallop pointed
• caml_ml_set_binary_mode and caml_ml_set_buffered look suspicious as well
• caml_ml_pos_in looks suspicious

Basically it looks like we should always root the channel argument for safety reasons, and justify with a comment the rare cases where we intentionally decide not to.

I propose a more systematic approach in #12445 which adds roots to many more functions.

I don’t think these other functions are affected - the backup thread only picks up a GC if the domain’s thread has released the domain lock. In caml_ml_set_channel_name et al, the domain lock is never released, so the scenario can’t arise - the STW section won’t start until the C call finishes. (edit: this isn't true... see below)

I don’t think these other functions are affected - the backup thread only picks up a GC if the domain’s thread has released the domain lock. In caml_ml_set_channel_name et al, the domain lock is never released, so the scenario can’t arise - the STW section won’t start until the C call finishes.

I don't know enough about the OCaml 5 GC to agree or disagree with this. However, if you have multiple threads, both in OCaml 4 and in OCaml 5, Lock(chan) can enter a blocking section (if the channel lock is already taken), and then another thread can run and trigger a GC. So, I agree with @yallop and @gasche that caml_ml_close_channel is not the only problematic function.

Ah, I see (and I'd failed to see that @yallop had said that too) - the domain lock may be released in Lock.

Superseded by #12445, which is now merged.