The function C_execute forks the current process and in the child process it uses some R API (example).
The potential issue with that is that, e.g., with the ALTREP framework STRING_ELT can do more complex things than just a memory read and executing those in the child process may not work correctly. For example, STRING_ELT could use rJava, which embeds JVM, and invoking that in the forked child will fail (in general forked JVM is probably not going to work at all, but it's fine if you call execvp after the fork without calling into the JVM in between), or it can use thread local storage, or something else that doesn't play well with forking.
The function
C_execute
forks the current process and in the child process it uses some R API (example).The potential issue with that is that, e.g., with the
ALTREP
frameworkSTRING_ELT
can do more complex things than just a memory read and executing those in the child process may not work correctly. For example,STRING_ELT
could userJava
, which embeds JVM, and invoking that in the forked child will fail (in general forked JVM is probably not going to work at all, but it's fine if you callexecvp
after thefork
without calling into the JVM in between), or it can use thread local storage, or something else that doesn't play well with forking.I found out while trying to get
sys
working on FastR, which itself is a JVM (https://github.com/oracle/fastr/issues/63).One way to fix this would be to move usages of R API before the
fork()
call. patch