Gabriel Scherer

Well `caml_shutdown` will collect runtime resources, unmap the minor-heap memory, etc., so of course any remaining mutators will crash big time. I don't think there is much to debug as...

Re. fixing other instances: as I [mentioned previously](https://github.com/ocaml/ocaml/pull/12737#issuecomment-1815271861), personally I expect that this idiom is very common -- people accessing immediate values within blocking sections, as it is known that...

Personally I prefer the "dumb" approach where we register all values as root, unless there are clear performance reasons to do differently. Should we update the manual to emphasize our...

I agree that there is no point in changing code that uses `Int_val(...)` in a critical section if the value is not registered as a root. But when it is...

Some of the other occurrences you listed (not all) also register the value, for example I looked at random at write_unix.c and the occurrence in `caml_unix_write_bigarray` seems faulty.

Full list of fragile `Int_val` calls: - [ ] `caml_unix_write_bigarray` in write_unix.c - [ ] `caml_unix_socketpair` in socketpair_win32.c - [ ] `caml_unix_read_bigarray` in read_unix.c - [ ] `caml_unix_open` in open_unix.c...

Full list for `Long_val`: - [ ] `caml_unix_truncate` in truncate_unix.c - [ ] `caml_unix_truncate` in truncate_win32.c

Yes, of course, and contributions would be welcome :-)

(cc @MisterDA who might be interested in this as well.) @emillon : are you planning to fix the subset of accesses that we found to be problematic as well, or...

Thanks! (The items look "checked" on your version of the list, but the PR still has only one case fixed, this is all fine.)