You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today I've looked at this a bit deeper. What happens it that multiple isolates run this process_run_test.dart code which makes a temporary directory, copies the process_test binary into it and runs it.
My first thought is that the random number generator will cause collisions in the temporary directory names, thereby making two isolates run in the same temp dir which would race on running & deleting that executable. Though it doesn't "seem" like this is happening.
The root cause is that the subprocess (after fork()ing) calls execvp and gets ETXTBSY. There's a special mention about this in the manpage:
The behavior of execlp() and execvp() when errors occur while attempting to execute the file is historic practice, but has not traditionally been documented and is not specified by the POSIX standard.
BSD (and possibly other systems) do an automatic sleep and retry if ETXTBSY is encountered.
Linux treats it as a hard error and returns immediately.
So we're observing the Linux treats it as a hard error situation.
Though I have been so far unable to identify what other thread / process may have the very same binary opened in write mode. It is written once (with a File.copySync()) and not touched until the exec().
In any case - this is dart:io related so I'm going to exclude this test from the iso-stress builder.
Log:
https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8824432375318156721/+/u/Run_Isolate_Stress_Tests_shard_1/task_stdout_stderr:_Run_Isolate_Stress_Tests_shard_1
/cc @aam @mkustermann
The text was updated successfully, but these errors were encountered: