| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
file and not the server.
This is so that the server does as few things as possible before exec() (preferably, nothing) so that we don't accidentally call malloc() which would make it possible to deadlock if the server spawned multiple threads before ExecuteDaemon().
RELNOTES: None.
PiperOrigin-RevId: 155603273
|
|
|
|
|
|
| |
See breakage @ http://ci.bazel.io/view/Bazel%20bootstrap%20and%20maintenance/job/Bazel/JAVA_VERSION=1.8,PLATFORM_NAME=freebsd-11/1481/console.
PiperOrigin-RevId: 155517063
|
|
|
|
| |
PiperOrigin-RevId: 155491277
|
|
|
|
|
|
|
|
| |
By this time (6 months later) Bazel clients should no longer need
this.
Change-Id: Ib058065a0ff3eedc777e95c7d06602ca6744d42a
PiperOrigin-RevId: 155478543
|
|
|
|
|
|
|
|
|
| |
It provides a single and clean way to output warning messages,
and replaces the fprintf(stderr, "Warning: ...\n") or
fprintf(stderr, "WARNING: ...\n") calls.
Change-Id: I2f8a8f659085b9e57a08b5208a8b8f683a7cd72c
PiperOrigin-RevId: 155386233
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-1 is not a valid port number and thus do not mean "no gRPC command server".
If you try to pass -1 to command_port you get:
$ bazel --command_port=-1 build //...
Invalid argument to --command_port: '-1'.
Must be a valid port number or 0.
Change-Id: I6c17167f6a285b21fcd064cea8bdc7e6770ac984
PiperOrigin-RevId: 155352835
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement proper aliveness check for the Bazel
server.
This allows detecting a server death that occurs
after the Java process started but before it
started the gRPC server.
On other platforms we open an anonymous pipe, let
the server inherit the writing end, close the
writing end in the client, and attempt to read
non-blockingly in order to check if the server is
still alive.
This approach fails on Windows because anonymous
pipes are always blocking. Named pipes support
asynchronous access but it's much simpler to just
check if the process exited. GetProcessTimes looks
like a reliable way to do so, and that's what we
use on Windows now.
Fixes https://github.com/bazelbuild/bazel/issues/2817
Change-Id: Ic24577d8440eb0c8188c852e2501ce1e254ba9fd
PiperOrigin-RevId: 154283585
|
|
|
|
|
|
|
|
| |
It does not need to be a fully allocated std::string every time.
A simple character constant is enough for it.
Change-Id: I98b9d4bb77932ea18646fbc793132e089bc66124
PiperOrigin-RevId: 154054987
|
|
|
|
|
|
|
|
| |
It is not necessary to have these function declarations (prototypes)
because they are declared+defined before they are actually called.
Change-Id: I32d9ba82e056e368eecc553569231ad1174ad5e0
PiperOrigin-RevId: 154035760
|
|
|
|
| |
PiperOrigin-RevId: 154017157
|
|
|
|
|
|
|
|
| |
This logger makes it easier to parse log statements and is now enabled for Bazel's java.log.
RELNOTES[INC]: Bazel now prints logs in single lines to java.log
PiperOrigin-RevId: 152954337
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement blaze::AcquireLock and ReleaseLock.
These methods implement the Bazel client-level
locking, whose purpose is to detect concurrently
running Bazel instances attempting to write to the
same output directory.
The Bazel server also detects this case (see
BlazeCommandDispatcher) but the client needs to
start the server first, meaning this cannot detect
races between clients that are in the middle of
installing.
You can see this locking in effect if you run
`bazel --output_user_root=/c/foo build src:bazel`
in one terminal, then run
`bazel --output_user_root=/c/foo help` in another
but the same working directory. The
second one will say "Another command is running."
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2647
RELNOTES: none
PiperOrigin-RevId: 152919185
|
|
|
|
|
|
|
| |
fprintf(stderr, "\nCannot write to %s; exiting...\n\n", broken_pipe_name);
Closes #2736.
PiperOrigin-RevId: 152675241
|
|
|
|
|
|
|
| |
Write a new function that dedupes a set of paths using its canonical
form and use it to remove possible duplicates in the set of rc files
that will be parsed.
PiperOrigin-RevId: 152489149
|
|
|
|
|
|
|
|
|
| |
The user interface is not changing. The policy will still be accepted as a flag passed to the client, as a startup flag (before the command), it will just no longer trigger server restarts and will not be passed on to a bazel server as part of the startup arguments. In batch mode, however, it will still be a startup argument, because the RunRequest proto is not sent, and all invocations restart bazel in batch mode anyway.
Since invocation policy only affects command arguments, and changes in command arguments do not cause server restarts, this is consistent with other server restart behavior.
RELNOTES: Changing --invocation_policy will no longer force a server restart.
PiperOrigin-RevId: 152426207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bugfixed version of
https://cr.bazel.build/9520 which broke some
Google-internal tests.
This change allows removing duplicate code:
ReadDirectorySymlink was implemented on Windows as
a junction resolver, which is also implemented in
file_windows.cc. Now it uses the JunctionResolver.
RELNOTES: none
PiperOrigin-RevId: 151691895
|
|
|
|
|
|
|
| |
GetVersionEx is discouraged by MSDN, so use the
recommended method to check the Windows version.
PiperOrigin-RevId: 151553827
|
|
|
|
|
|
|
|
| |
Ability to configure this was added to provide an easy correction in case
writing the exit code to a file proved problematic. This feature has been out
for 3 months with no reported issues, no reason to keep the extraneous flag.
PiperOrigin-RevId: 151496431
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change blaze::ConvertPath to lower-case its result
for sake of deterministic comparison later.
Change blaze::CompareAbsolutePaths to call
blaze::ConvertPath before comparison.
The ConvertPath method normalizes its input then
converts it to lowercase, meaning
ConvertPath("c:/Foo") and ConvertPath("C:\FOO\.")
will give the same result.
Thanks to this we will no longer kill the Bazel
server if the --output_user_root changes but only
in casing, or by adding/removing trailing
slash/backslash.
Fixes https://github.com/bazelbuild/bazel/issues/2714
--
Change-Id: I36c13378a9e3567862ee1c611f56b0c3ab465da8
Reviewed-on: https://cr.bazel.build/9517
PiperOrigin-RevId: 151425571
MOS_MIGRATED_REVID=151425571
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 151145409
MOS_MIGRATED_REVID=151145409
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create a method in blaze_util_<platform> to
retrieve the path to the home dir ($HOME on
Linux/macOS, %USERPROFILE% on Windows), where we
look for the user's bazelrc file (".bazelrc").
--
Change-Id: I86be1dbe1f992ad55eb09b496024754099d54912
Reviewed-on: https://cr.bazel.build/9513
PiperOrigin-RevId: 151004759
MOS_MIGRATED_REVID=151004759
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make it more robust: it now works with Cygwin too,
e.g. BAZEL_SH=c:/cygwin64/bin/bash.exe
See https://github.com/bazelbuild/bazel/issues/2725
Related to https://github.com/bazelbuild/bazel/issues/2447
--
Change-Id: I911f09acd3e39c7cd0fe0750774fa0a900ffd844
Reviewed-on: https://cr.bazel.build/9510
PiperOrigin-RevId: 150885982
MOS_MIGRATED_REVID=150885982
|
|
|
|
|
|
|
|
| |
--
Change-Id: I6ff757500085daa4c440a3ef41d02e6c664b9f3d
Reviewed-on: https://cr.bazel.build/9466
PiperOrigin-RevId: 150857712
MOS_MIGRATED_REVID=150857712
|
|
|
|
|
|
|
|
|
|
|
| |
Using ::SetConsoleCtrlHanlder() Win32 API.
Tested manually (not sure how to test this automatically :()
--
Change-Id: Ibb5b311d6412d77d16a7f7c1658a9f3435d3cd55
Reviewed-on: https://cr.bazel.build/9464
PiperOrigin-RevId: 150760724
MOS_MIGRATED_REVID=150760724
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not attempt to kill the server process if it's
already dead. This gets rid of the spurious "Could
not terminate process (Access Denied)" errors,
which we got for attempting to TerminateProcess
twice (without checking whether the process was
still alive), because we apparently assumed that
if we can get a HANDLE to the process then it must
be alive, which is not true.
This is a follow-up to unknown commit.
Fixes https://github.com/bazelbuild/bazel/issues/2684
--
PiperOrigin-RevId: 150735254
MOS_MIGRATED_REVID=150735254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the (spurious) error messages about the Bazel
client's failure to kill the server process, with
"Access Denied" errors.
This was caused by our attempt to kill the server
process twice, and the error was coming from the
second attempt.
The culprit was an unimplemented
VerifyServerProcess method (which ensures that the
PID read from the server.pid.txt indeed refers to
a running Bazel server) which always returned
false, to avoid accidentally killing an unrelated
process that got the same PID as the last alive
Bazel server.
The new code follows the same logic as the Linux
version of Bazel, namely storing the process'
start time in a file next to the PID file, and
checking that the process with said PID was
indeed started at the time we read from the file.
This change also fixes a problem that the now
working VerifyServerProcess uncovered: we need to
wait for the previous Bazel server to properly
shut down before we can open the new jvm.out log
file.
Fixes https://github.com/bazelbuild/bazel/issues/2684
--
PiperOrigin-RevId: 150632429
MOS_MIGRATED_REVID=150632429
|
|
|
|
|
|
|
|
| |
Roll forward commit ae4b02fb21772effd6836599a7e1792b26ff95e0.
--
PiperOrigin-RevId: 150627891
MOS_MIGRATED_REVID=150627891
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're using Azul Systems, Inc.'s Zulu® OpenJDK build[1], as it's a good
vanilla build of OpenJDK available for our three most important
platforms:
zulu8.20.0.5-jdk8.0.121-linux_x64.tar.gz
zulu8.20.0.5-jdk8.0.121-macosx_x64.zip
zulu8.20.0.5-jdk8.0.121-win_x64.zip
You can build & run a Bazel binary with an embedded JDK by simple doing:
bazel build //src:bazel_with_jdk
bazel-bin/src/bazel_with_jdk info
The "bazel license" command prints the license of the embedded OpenJDK.
We mirror the binaries and sources of the OpenJDK used for bundling on
this website:
https://bazel-mirror.storage.googleapis.com/openjdk/index.html
RELNOTES: Bazel can now be built with a bundled version of the OpenJDK.
This makes it possible to use Bazel on systems without a JDK, or where
the installed JDK is too old.
[1] http://www.azul.com/downloads/zulu/
--
PiperOrigin-RevId: 150440467
MOS_MIGRATED_REVID=150440467
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broken MSVC Bazel build on CI
https://github.com/bazelbuild/bazel/issues/2695
--
PiperOrigin-RevId: 150423895
MOS_MIGRATED_REVID=150423895
|
|
|
|
|
|
|
|
| |
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 150314355
MOS_MIGRATED_REVID=150314355
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix 3 bugs in blaze_util_windows:
- off-by-one error in the loop ensuring the std
handles are all open
- don't auto-close stdout's HANDLE after querying
the console window's size
- error-handling for when stdout is redirected
thus ::GetStdHandle returns an invalid handle
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 150310578
MOS_MIGRATED_REVID=150310578
|
|
|
|
|
|
|
|
| |
This is prone to deadlock.
--
PiperOrigin-RevId: 150263255
MOS_MIGRATED_REVID=150263255
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support drive roots as --output_user_root values,
so "d:\" and "d:/" will now work. However "d:"
doesn't work yet because that's shorthand for the
current working directory on "D:".
See https://github.com/bazelbuild/bazel/issues/2683
--
PiperOrigin-RevId: 150203657
MOS_MIGRATED_REVID=150203657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reasoning: It never worked anyway, because Bazel didn't set the
JOB_OBJECT_LIMIT_BREAKAWAY_OK limit on its job. This is why running
Bazel in batch mode inside a shell integration test on Windows caused a
"CreateProcess() failed: access denied" error.
By no longer using CREATE_BREAKAWAY_FROM_JOB, this will instead cause us
to use nested jobs, which is exactly the right thing to do:
- If our parent dies, we and our children still get reliably killed.
- But if *only* we die, then just our children will be reliably killed.
If we're on an older Windows that doesn't support nested jobs and are
running inside an existing job, we should assume that our parent handles
process management - for example like Bazel, which runs all spawned
processes in their own job.
Also remove the CREATE_NEW_PROCESS_GROUP flag in Bazel's batch mode,
because I can't see how this makes sense for a non-daemon process.
--
PiperOrigin-RevId: 150194586
MOS_MIGRATED_REVID=150194586
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the bug that the MSYS-less client couldn't
connect to the freshly started server and had to
be started again.
Fixes https://github.com/bazelbuild/bazel/issues/2672
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 150069285
MOS_MIGRATED_REVID=150069285
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix blaze_util_windows::ConvertAbsolutePaths,
which happens to have been the culprit why the
MSYS-less Bazel would always kill the running
server.
Fixes https://github.com/bazelbuild/bazel/issues/2672
See https://github.com/bazelbuild/bazel/issues/2107
--
Change-Id: I873a78c737a6d6906ac7db9bcd0e7186e17bd7ca
Reviewed-on: https://cr.bazel.build/9355
PiperOrigin-RevId: 150052180
MOS_MIGRATED_REVID=150052180
|
|
|
|
|
|
|
|
|
|
| |
The log size is specified in number of bytes, not number of records, and
the previous 50k limit was too small to hold any significant amount of
data. 10M should be good to hold enough to troubleshoot issues.
--
PiperOrigin-RevId: 149660970
MOS_MIGRATED_REVID=149660970
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the path limit for non-UNC-prefixed paths when
using CreateDirectoryW. According to MSDN [1],
this is only 248 chars, as opposed to the usual
260 (MAX_PATH).
See https://github.com/bazelbuild/bazel/issues/2107
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363855(v=vs.85).aspx
--
PiperOrigin-RevId: 149627964
MOS_MIGRATED_REVID=149627964
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Windows-implementation of this function
shortens paths that we pass to the JVM, such as
the Bazel server jar's path, the log file path,
etc. These must be shortened because the JVM
doesn't handle long paths.
We don't shorten paths passed to the Bazel server
itself though because Bazel can handle long paths.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 149548361
MOS_MIGRATED_REVID=149548361
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After this change, a msys bazel can be built with
a MSVC-default Bazel by adding --cpu=x64_windows_msys --host=x64_windows_msys
See https://github.com/bazelbuild/bazel/issues/2627
--
Change-Id: Iaa82bf4dd911c5740b98d3b2739dfccca6203f79
Reviewed-on: https://cr.bazel.build/9293
PiperOrigin-RevId: 149532274
MOS_MIGRATED_REVID=149532274
|
|
|
|
|
|
|
|
| |
--
Change-Id: Ie1f3be6258f024d352ff4571a5355660f409f70d
Reviewed-on: https://cr.bazel.build/9291
PiperOrigin-RevId: 149470780
MOS_MIGRATED_REVID=149470780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the --ignore_client_env flag a no-op.
The client will pass --client_env flags to the
server even in --batch mode. This simplifies the
code as well as ensuring that the server always
uses the up-do-date client environment.
We'll gradually get rid of all System.getenv calls
in the server, because the server should always
respect the client env.
Roll forward of 149403129 with fixes.
--
PiperOrigin-RevId: 149435060
MOS_MIGRATED_REVID=149435060
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
broke //src/test/shell/bazel:bazel_bootstrap_distfile_test
*** Original change description ***
Env.vars: server won't ignore the client env
Make the --ignore_client_env flag a no-op.
The client will pass --client_env flags to the
server even in --batch mode. This simplifies the
code as well as ensuring that the server always
uses the up-do-date client environment.
We'll gradually get rid of all System.getenv calls
in the server, because the server should always
respect the client env.
--
PiperOrigin-RevId: 149416602
MOS_MIGRATED_REVID=149416602
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the --ignore_client_env flag a no-op.
The client will pass --client_env flags to the
server even in --batch mode. This simplifies the
code as well as ensuring that the server always
uses the up-do-date client environment.
We'll gradually get rid of all System.getenv calls
in the server, because the server should always
respect the client env.
--
PiperOrigin-RevId: 149403129
MOS_MIGRATED_REVID=149403129
|
|
|
|
|
|
|
|
| |
We already constructed it in the code via blaze_util::AsShortWindowsPath, but accidentally didn't use the results.
--
PiperOrigin-RevId: 149398556
MOS_MIGRATED_REVID=149398556
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix blaze_util_windows.ConvertPath: in the MSVC
version this is using the actual %PATH% value, we
don't need to convert it.
Fix blaze_util_windows.PathAsJvmFlag: shorten the
path so we can pass it to the JVM process (long
paths aren't understood by the shell), but also
converrt backslashes to forward slashes so the JVM
won't believe we are passing paths with escaped
characters.
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 149396971
MOS_MIGRATED_REVID=149396971
|
|
|
|
|
|
|
|
| |
This was breaking the CI.
--
PiperOrigin-RevId: 149300839
MOS_MIGRATED_REVID=149300839
|
|
|
|
|
|
|
|
|
|
|
| |
Mimic read(2) behavior when reading from /dev/null
and always successfully read 0 bytes.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 149286494
MOS_MIGRATED_REVID=149286494
|
|
|
|
|
|
|
|
|
|
| |
This method now works for non-existent paths too.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 149284633
MOS_MIGRATED_REVID=149284633
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 149282686
MOS_MIGRATED_REVID=149282686
|