Make Unix.create_process_env
thread-safe in all cases
#12404
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If neither
spawnp
norexecvpe
are provided by the C library, the emulation code in otherlibs/unix, which is based onfork
, ended up allocating memory in the child process usingmalloc
.This is not thread-safe: if the
fork
occurs while another OCaml domain or C thread is running insidemalloc
, the child process can inherit a memory state where it's unsafe to domalloc
. For example, the mutex protectingmalloc
is locked, because it was locked atfork
time, but the other thread is no longer there to finish themalloc
and unlock the mutex, somalloc
deadlocks in the child process.This PR proposes a simple fix: in the child process, instead of calling our
malloc
-based emulation ofexecvpe
, we just setenviron
to the desired environment and callexecvp
. This is safe because no other thread is running in the child process, so nobody can observe the change to the global variableenviron
.Fixes: #12395.