| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We found that with JDK9 and up Bazel would sometimes crash
with a StackOverflowError in one of the Command-Accumulator-Thread-*
threads. We experimentally found that this error was due to these
threads being constrained to a 32KiB stack size. The default stack
size for JVM threads on most 64-bit systems is 1MiB (So that's 3%
of the default). The purpose of the Command-Accumulator-Threads
is to read stdout/stderr from processes that Bazel launches locally.
The proposed fix is to just use the system default stack size for
these threads. The alternative is to increase the size limit to
some arbitrary number that happens to work, but this is likely
premature optimization and I'd like to avoid that if possible. We
further found that this code even predates Blaze/Bazel and is
from 2005.
PiperOrigin-RevId: 208009940
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refocus synchronization mechanism to cope with file descriptor set fork-
induced races to more tightly constrain concurrent fork/exec pairs. This
problem has been observed in bazel proper repeatedly, exhibiting as the
iconic ETXTBSY - Text file busy in wide worker pool builds and tests.
Evidence that this was discovered by @buchgr is in the comment and change
to the embedded ExecutionService implementation, and the description of
the race and the need for the synchronization was lifted from that scope
to the JavaSubprocessFactory. This factory is a singleton and represents
the gateway to all worker process execution, and serves as the correct
lock primitive to ensure that file descriptor sets are not duplicated
across forks, which gave rise to this issue.
To test this, I demonstrated a reproducer presented at
https://bugs.java.com/view_bug.do?bug_id=8068370
with 2.4% of invocations in that pathological case exhibiting the issue.
With a functionally equivalent change - synchronizing around a
processBuilder.start() call - as the only modification to the reproducer,
no further failures of any kind were observed, over several hundred runs.
Closes #5556.
PiperOrigin-RevId: 203947224
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/656a0bab1e025ff3c27d595284a4bf1c5a8d8028 with test (unknown commit) and fix.
Big round of sandbox fixes / performance improvements.
- The number of stat() syscalls in the SymlinkedSandboxedSpawn was way too high. Do less, feel better.
- When using --experimental_sandbox_base, ensure that symlinks in the path are resolved. Before this, you had to check whether on your system /dev/shm is a symlink to /run/shm and then use that instead. Now it no longer matters, as symlinks are resolved.
- Remove an unnecessary directory creation from each sandboxed invocation. Turns out that the "tmpdir" that we created was no longer used after some changes to Bazel's TMPDIR handling.
- Use simpler sandbox paths, by using the unique ID for each Spawn provided by SpawnExecutionPolicy instead of a randomly generated temp folder name. This also saves a round-trip from our VFS to NIO and back. Clean up the sandbox base before each build to ensure that the unique IDs are actually unique. ;)
- Use Java 8's Process#isAlive to check whether a process is alive instead of trying to get the exitcode and catching an exception.
Closes #4913.
PiperOrigin-RevId: 193031017
|
|
|
|
| |
PiperOrigin-RevId: 191642942
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The number of stat() syscalls in the SymlinkedSandboxedSpawn was way too high. Do less, feel better.
- When using --experimental_sandbox_base, ensure that symlinks in the path are resolved. Before this, you had to check whether on your system /dev/shm is a symlink to /run/shm and then use that instead. Now it no longer matters, as symlinks are resolved.
- Remove an unnecessary directory creation from each sandboxed invocation. Turns out that the "tmpdir" that we created was no longer used after some changes to Bazel's TMPDIR handling.
- Use simpler sandbox paths, by using the unique ID for each Spawn provided by SpawnExecutionPolicy instead of a randomly generated temp folder name. This also saves a round-trip from our VFS to NIO and back. Clean up the sandbox base before each build to ensure that the unique IDs are actually unique. ;)
- Use Java 8's Process#isAlive to check whether a process is alive instead of trying to get the exitcode and catching an exception.
Closes #4913.
PiperOrigin-RevId: 190472170
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove Optional<> where it's not needed. It's nice for return values, but IMHO it was overused in this code (e.g. Optional<List<X>> is an anti-pattern, as the list itself can already signal that it is empty).
- Use Bazel's own Path class when dealing with paths, not String or java.io.File.
- Move LinuxSandboxUtil into the "sandbox" package.
- Remove dead code and unused fields.
- Migrate deprecated VFS method calls to their replacements.
- Fix a bug in ExecutionStatistics where a FileInputStream was not closed.
Closes #4868.
PiperOrigin-RevId: 190217476
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
child of the process where the Blaze client itself was run.
Limitations:
- Untested on Windows; it should work because ExecuteProgram() is implemented there, too, but since Windows doesn't support exec(), there is at least one process in between
Progress towards #2815.
RELNOTES[NEW]: The new "--direct_run" flag on "blaze run" lets one run interactive binaries.
PiperOrigin-RevId: 184528845
|
|
|
|
|
|
|
| |
In particular, provide all of the statistics available from the getrusage() system call.
RELNOTES: None.
PiperOrigin-RevId: 178162687
|
|
|
|
|
|
|
| |
ExecutionStatisticsProvider.
RELNOTES: None.
PiperOrigin-RevId: 178056182
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 177290508
|
|
|
|
|
|
|
| |
TerminationStatus, and also add a TerminationStatus.Builder and tests.
RELNOTES: None.
PiperOrigin-RevId: 174557303
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two close operations were added to work around #1708, but caused #2675.
We found the root cause of the hanging problem in #1708 is a race
condition when creating Windows processes:
When Bazel trys to create two processes, one for a local command
execution, one for starting the worker process. The worker process
might accidentally inherits handles opened when creating the local
command process, and it holds those handles as long as it lives.
Therefore, ReadFile function hangs when handles for the write end of
stdout/stderr pipes are released by the worker.
The solution is to make Bazel native createProcess JNI function
explicitly inheirts handles as needed, and use this function to start
worker process.
Related: http://support.microsoft.com/kb/315939
Fixed https://github.com/bazelbuild/bazel/issues/2675
Change-Id: I1c9b1ac3c9383ed2fd28ea92f528f19649693275
PiperOrigin-RevId: 173244832
|
|
|
|
| |
PiperOrigin-RevId: 168802886
|
|
|
|
|
|
|
|
|
|
|
| |
Also move the implementation of FutureCommandResult to a top-level class.
This is in preparation for significantly simplifying the shell library. The
plan is to remove the Subprocess abstraction, and have lower-level
implementations implement the much simpler FutureCommandResult interface
instead.
PiperOrigin-RevId: 167844736
|
|
|
|
|
|
|
|
|
| |
Split collect, concurrent, vfs, windows into package-level BUILD files.
Move clock classes out of "util", into their own Java package.
Move CompactHashSet into its own Java package to break a dependency cycle.
Give nestedset and inmemoryfs their own package-level BUILD files.
PiperOrigin-RevId: 167702127
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 167574104
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 167505493
|
|
|
|
|
|
|
|
| |
BUILD files.
Replace all ":relative" labels with "//absolute:path" labels for easier search & replace.
PiperOrigin-RevId: 167500985
|
|
|
|
| |
PiperOrigin-RevId: 166849610
|
|
|
|
| |
PiperOrigin-RevId: 164827022
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Important: the simplified API now defaults to forwarding interrupts to
subprocesses. I did audit all the call sites, and I think this is a safe change
to make.
- Properly support timeouts with all implementations
- Simplify the API
- only provide two flavours of blocking calls, which require no input and
forward interrupts; this is the most common usage
- provide a number of async calls, which optionally takes input, and a flag
whether to forward interrupts
- only support input streams, no byte arrays or other 'convenience features'
that are rarely needed and unnecessarily increase the surface area
- use java.time.Duration to specify timeout; for consistency, interpret a
timeout of <= 0 as no timeout (i.e., including rather than excluding 0)
- KillableObserver and subclasses are no longer part of the public API, but
still used to implement timeouts if the Subprocess.Factory does not support
them
- Update the documentation for Command
- Update all callers; most callers now use the simplified API
PiperOrigin-RevId: 164716782
|
|
|
|
| |
PiperOrigin-RevId: 153444516
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147716435
MOS_MIGRATED_REVID=147716435
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make it part of the interface contract that the
argv[0] must be either absolute or just a file
name. The only caller has been adhering to this
contract already, but document it explicitly
still.
--
PiperOrigin-RevId: 144447641
MOS_MIGRATED_REVID=144447641
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=131620345
|
|
|
|
|
|
|
| |
rolling our own in Consumers.
--
MOS_MIGRATED_REVID=130936036
|
|
|
|
|
|
|
| |
Makes #1664 much less acute.
--
MOS_MIGRATED_REVID=130750731
|
|
|
|
|
|
|
|
|
|
|
| |
1. Return EOF for streams representing Windows process pipes.
2. Fix the timing of process.close()
3. Un-synchronized reading of stderr and stdout.
--
Change-Id: Iec98f45db9984be2c2b066962801cbd3ca60da3f
Reviewed-on: https://bazel-review.googlesource.com/#/c/4000/
MOS_MIGRATED_REVID=126910063
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Apparently we now try to open output files for the process twice: once when we are constructing the output streams, and the second time when we tell the process to redirect its outputs. This causes the outputs to be empty on Windows
*** Original change description ***
Do redirection of stdout / stderr in Java instead of reimplementing it in every process wrapper again.
--
MOS_MIGRATED_REVID=126801016
|
|
|
|
|
|
|
|
|
| |
Subprocesses now get killed if the Bazel server itself is killed and so do their subprocesses.
Also implemented Subprocess#close() so that we get a little more control over when the native structures are cleaned up.
--
MOS_MIGRATED_REVID=126628000
|
|
|
|
|
|
|
| |
We should really do something about the mess that is loading our JNI libraries -- io.bazel.EnableJNI is mentioned eight times in the code in various diverse contexts. This change is not the right place to do it, though.
--
MOS_MIGRATED_REVID=126570481
|
|
|
|
|
|
|
|
|
|
|
| |
to Windows process management.
With this change, Bazel can build itself using native Windows process management and Ctrl-C works in server mode as expected. Yay!
Flipping the flag will come in a separate change that's easy to roll back if need be.
--
MOS_MIGRATED_REVID=126408264
|
|
|
|
|
|
|
| |
implementation can eventually be plugged in.
--
MOS_MIGRATED_REVID=126404913
|
|
|
|
|
|
|
| |
every process wrapper again.
--
MOS_MIGRATED_REVID=126279021
|
|
|
|
|
|
|
|
|
| |
This is the first actual use of Windows JNI!
Also a cleanup of ProcessUtils. Injecting a mock implementation was never used.
--
MOS_MIGRATED_REVID=126068832
|
|
|
|
|
|
|
| |
Thread#interrupt() .
--
MOS_MIGRATED_REVID=125933542
|
|
|
|
|
|
|
|
|
| |
According to https://bugs.openjdk.java.net/browse/JDK-4311711 , the behavior is undefined and it reproducibly results in hangs on Windows.
This makes Ctrl-C on be able to interrupt Bazel during the execution phase, too. There are no guarantees about actually killing the child processes, though: Process.destroy() apparently leaves some child processes running. Unfortunately, Java doesn't offer a solution to this, so we'll have to resort to native code in some way.
--
MOS_MIGRATED_REVID=125758911
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=115063418
|
|
|
|
|
|
|
| |
Needed for #276.
--
MOS_MIGRATED_REVID=114838538
|
|
|
|
|
|
|
|
|
|
|
| |
The headers were modified with
`find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'`
And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan.
The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand.
--
MOS_MIGRATED_REVID=103938715
|
|
|
|
|
|
|
| |
become zombies.
--
MOS_MIGRATED_REVID=103541217
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=102332437
|
|
|
|
|
|
|
| |
have lots of threads.
--
MOS_MIGRATED_REVID=101485204
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=87821306
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=86427416
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=85874067
|
|
--
MOE_MIGRATED_REVID=85702957
|