| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Terminate processes and job objects with non-zero
exit code.
Zero was the most unfortunate exit code possible
because it made the Java side believe that the
process exited successfully.
There's another bug in the Java side too where
StandaloneSpawnStrategy ignores the thread's
interruption state. I'll fix that in a separate
change.
Fixes https://github.com/bazelbuild/bazel/issues/2774
Change-Id: I01b3d95848cb04618395c9ef2fa0d1a406b25cca
PiperOrigin-RevId: 152119343
|
|
|
|
|
|
|
|
|
|
| |
Came up while working on https://github.com/bazelbuild/bazel/issues/2725
--
Change-Id: I923690642d0fc93dcdb5050837b5ddaaa2a1d494
Reviewed-on: https://cr.bazel.build/9469
PiperOrigin-RevId: 150880961
MOS_MIGRATED_REVID=150880961
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added support for Enterprise, Professional, and Community editions of Microsoft Visual Studio 2017.
In the Community edition, the working directory changes after vcvarsall.bat is called. Not sure why.
Closes #2658.
--
Reviewed-on: https://github.com/bazelbuild/bazel/pull/2658
PiperOrigin-RevId: 150203876
MOS_MIGRATED_REVID=150203876
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pthread mutexes must be initialized with pthread_mutex_init and cleaned
up with pthread_mutex_destroy.
This seems to fix a race where poll() would access invalid array indexes
on an array constructed based on the size of a shared list protected by
the mutex. This is understandable because the mutex may not have been
doing anything due to the lack of its proper initialization -- and, if
so, I'm surprised the consequences were not more catastrophic.
As with any race condition, it is hard to confirm that this fixes the
observed problem, but I could trivially reproduce this issue earlier
and now I cannot with this fix after tens of runs. See reproduction
code in the referenced bug for details on how to expose the issue.
Fixes #1676.
--
Change-Id: Ia5a4a8f12da7c3780f33266b9922eeba7645b3a4
Reviewed-on: https://cr.bazel.build/9230
PiperOrigin-RevId: 149414125
MOS_MIGRATED_REVID=149414125
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More specifically, change windows_util.AsShortPath
to accept empty inputs, as well as paths with
forward slashes.
Also output more accurate error messages for bad
input paths than before.
This fixes //src/test/java/com/google/devtools/build/lib:windows-tests
but not //src/test/java/com/google/devtools/build/lib:standalone-tests
--
PiperOrigin-RevId: 149399449
MOS_MIGRATED_REVID=149399449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hard limit for SetCurrentDirectory{A,W} is
MAX_PATH-1, even with UNC prefix, therefore a
process' cwd may also not be longer than that.
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2406
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 149290147
MOS_MIGRATED_REVID=149290147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was previously in unix, but also used from non-unix file systems, which
means it's not actually unix-specific. This is in preparation for splitting
compilation of the unix and windows file systems into separate libraries.
That improves layering and reduces compile times - note that Bazel already
injects the vfs into its lower layers, which should only rely on the normal
vfs APIs, not on anything platform-specific.
--
PiperOrigin-RevId: 147829659
MOS_MIGRATED_REVID=147829659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the new CreateJunction in the Windows JNI code
every time we need to create junctions. This means
updating WindowsFileOperations and related tests.
Add test for WindowsFileSystem.createSymbolicLink.
See https://github.com/bazelbuild/bazel/issues/2238
--
Change-Id: I5827e2e70e8e147f5f102fabf95fa9a148b3bcdc
Reviewed-on: https://cr.bazel.build/8896
PiperOrigin-RevId: 147598107
MOS_MIGRATED_REVID=147598107
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a CreateJunction function in the Windows
JNI library. Also move a bit of code from
file_windows to the JNI library, where it is
(also) needed.
This implementation is an improved version of
`blaze_util::SymlinkDirectories` in
blaze_util_windows: this version handles Windows
paths as `name` and `target`, and performs more
validation (e.g. on the length of `target`), plus
has more comments explaining the logic. In a
subsequent change I'll start using this new
function in blaze_util_windows.
This method will also be helpful in tests: we will
no longer have to shell out to mklink.
See https://github.com/bazelbuild/bazel/issues/2107
--
Change-Id: I7e9b085fdc2ba47be83da5319bded02bd323e71b
Reviewed-on: https://cr.bazel.build/8892
PiperOrigin-RevId: 147585207
MOS_MIGRATED_REVID=147585207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now Bazel can detect MSVC from Visual Studio 2017 or Visual C++ build
tools 2017.
Also modified build_windows_jni.sh to make it work with VS 2017.
Fixed: https://github.com/bazelbuild/bazel/issues/2440
--
Change-Id: I4afbce809ff74634f32fab87efe5e7f0b3f60c95
Reviewed-on: https://cr.bazel.build/8890
PiperOrigin-RevId: 147467993
MOS_MIGRATED_REVID=147467993
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the OpenDirectory helper method into the JNI
library. We'll need it there; a subsequent change
will make use of it there.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 147448792
MOS_MIGRATED_REVID=147448792
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add test helpers to recursively delete the
TEST_TMPDIR in the TearDown method of tests, to
ensure each test sees a fresh temp directory.
Also add tests for these test helpers.
--
PiperOrigin-RevId: 147135561
MOS_MIGRATED_REVID=147135561
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147008328
MOS_MIGRATED_REVID=147008328
|
|
|
|
|
|
|
|
|
|
|
| |
These changes addresses issues where Windows users have a space in their username. Allows the default output_base path to be used.
Closes #2491.
--
Reviewed-on: https://github.com/bazelbuild/bazel/pull/2491
PiperOrigin-RevId: 146773331
MOS_MIGRATED_REVID=146773331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In almost every place we compared paths against
MAX_PATH, we had it wrong. MAX_PATH is the
null-terminated maximum length, so paths exactly
MAX_PATH long (not counting the null-terminator)
were incorrectly considered short.
Also fix the error message in the MSVC python
wrapper, because it reported an incorrect path
length limit in the warning message.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 146762382
MOS_MIGRATED_REVID=146762382
|
|
|
|
|
|
|
|
|
|
|
| |
Also introduce a fail() method and clean up the
script a little bit.
Fixes https://github.com/bazelbuild/bazel/issues/2464
--
PiperOrigin-RevId: 146225020
MOS_MIGRATED_REVID=146225020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move JNI code from windows_file_operations.cc to
windows_processes.cc, so all the JNI code is now
in the latter.
This lets us expose windows_file_operations.* to
the Bazel client (via the ":windows_jni_lib"
target), so we can finally share file handling
logic between the Bazel client and the JNI
library.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 145063140
MOS_MIGRATED_REVID=145063140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extract a WinAPI call from the JNI method's body.
In a subsequent change I'll move all JNI methods
to a common location (windows_processes.cc) and
that will be the only file dealing with JNI stuff.
The rest of the windows_* sources will be exposed
in the //src/main/native:windows_jni_util library
so the Bazel client can also depend on it later.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 145062890
MOS_MIGRATED_REVID=145062890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a simple refactoring, no change in
functionality.
Create a windows_file_operations.h file, declare
windows_util::IsJunctionOrDirectorySymlink there,
We will include this file in the cc_library
//src/main/native:windows_jni_lib later and use
it from the Bazel client.
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 145062164
MOS_MIGRATED_REVID=145062164
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this change:
- rename //src/main/native:windows_jni_utils to
//src/main/native:windows_jni_lib and make it
visible to //src/main/cpp:__subpackages__ because
we will use some methods there from this library
- move AutoHandle into windows_util.h, we'll use
it from blaze_util_windows.cc / file_windows.cc
later
See https://github.com/bazelbuild/bazel/issues/2107
--
PiperOrigin-RevId: 144946842
MOS_MIGRATED_REVID=144946842
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add tests for the AsExecutablePathForCreateProcess
method, since its logic is pretty complex.
Unfortunately testing it also requires complex
logic, as we need to test what exactly happens
when the input path is shorter than MAX_PATH or
when it's longer than it. To test that reliably,
we need a base path that we know will not get
shortened. Creating that base path under the temp
directory is a nightmare, we need to:
(1) retrieve the temp dir, shorten it so we know
that it won't be shortened further
(2) keep creating subdirectories that have a short
name so they also won't get shortened, but keep
the entire path below MAX_PATH while leaving
enough space for a file name in the end
(3) append a file name such that the path is just
below MAX_PATH, or is exactly that long, or is
longer than it. Because of steps (1) and (2) we
can be sure that no other component in the path
will get shortened, so we can test exactly what's
going on with the shortener logic and its error
handling. But oh boy is it complicated.
Side note, we need to use the Widechar WinAPI
functions to create/delete the directories and
files, because the POSIX API on Windows appears to
be backed by the ASCII API functions, so
attempting to `mkdir` with a path longer than
CreateDirectoryA's limit is going to fail.
But on the positive side, adding tests caught two
bugs in the method, so we have that going for us
which is nice.
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 144823029
MOS_MIGRATED_REVID=144823029
|
|
|
|
|
|
|
|
|
|
| |
This change moves AsExecutablePathForCreateProcess
to windows_util. This is a follow-up to
unknown commit.
--
PiperOrigin-RevId: 144623760
MOS_MIGRATED_REVID=144623760
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prepare moving AsExecutableForCreateProcess into a
shared location where the Bazel client code can
also access it, since this logic is needed there
too.
This change is a simple refactor, it doesn't
affect any logic.
--
PiperOrigin-RevId: 144623656
MOS_MIGRATED_REVID=144623656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When spawning a new process with CreateProcessA,
convert argv0 to a 8dot3 style short path so we
can support longer paths than MAX_PATH. This is
the same approach we did in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb.
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 144613589
MOS_MIGRATED_REVID=144613589
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce helper classes whose d'tor automatically
release resources (close handles, release Java
object handles, etc) and get rid of the
"goto cleanup" pattern.
--
PiperOrigin-RevId: 144349886
MOS_MIGRATED_REVID=144349886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use CreateFileW to create the output files for
redirected stdout/stderr in nativeCreateProcess.
This way we can support long paths for these
files.
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 144311729
MOS_MIGRATED_REVID=144311729
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a separate argument to nativeCreateProcess for
argv[0] specifically, and another for the rest of
the args.
In a subsequent change I'll add code to compute
the 8dot3 style short name of the argv[0] so we
can use longer paths for executables in
CreateProcessA than we normally could. This is the
same approach as used in commit 44ecf9a0c7c25496a43f59f1c8f20df9527e12cb
See https://github.com/bazelbuild/bazel/issues/2107
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 144311562
MOS_MIGRATED_REVID=144311562
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 142430323
MOS_MIGRATED_REVID=142430323
|
|
|
|
|
|
|
|
| |
size while halving the number of syscalls required to get an MD5 of a file. This shaves a few hundred milliseconds off of startup time.
--
PiperOrigin-RevId: 142235555
MOS_MIGRATED_REVID=142235555
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a JNI method that can resolve 8dot3
style paths. This is necessary because we need to
be able to compare 8dot3 style paths and long
paths [1], and because implementing this correctly
in Java seems to be impossible [2].
This change also adds tests for the JNI isJunction
implementation.
See https://github.com/bazelbuild/bazel/issues/2101
[1] https://github.com/bazelbuild/bazel/issues/2145
[2] https://github.com/bazelbuild/bazel/issues/2145#issuecomment-266766716
--
PiperOrigin-RevId: 142123750
MOS_MIGRATED_REVID=142123750
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 141939490
MOS_MIGRATED_REVID=141939490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change:
- renames windows_error_handling.* to
windows_util.*
- moves most stuff except for the JNI method
implementations into the new windows_util
namespace
- implements a jstring to wchar string converter
- uses GetFileAttributesW in
windows_file_operations.cc
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 141187291
MOS_MIGRATED_REVID=141187291
|
|
|
|
|
|
|
|
|
|
|
| |
This way it's easier to find the functions we need
to change to widechar version.
See https://github.com/bazelbuild/bazel/issues/2181
--
PiperOrigin-RevId: 141043389
MOS_MIGRATED_REVID=141043389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move blaze::ReadFile and blaze::WriteFile to
file.h and file_platform.h (thus into the
blaze_util namespace), and update references.
This allows us to implement these methods in a
platform-specific way.
Also move UnlinkPath.
See https://github.com/bazelbuild/bazel/issues/2107
--
MOS_MIGRATED_REVID=140328273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
soon as they arrives
See https://developer.apple.com/reference/coreservices/1455376-fseventstreamcreateflags/kfseventstreamcreateflagnodefer?language=objc
Also added the integration test now it is no more flaky.
Tested with `bazel test src/test/java/com/google/devtools/build/lib/skyframe:SkyframeTests --runs_per_test 10 --test_filter=com.google.devtools.build.lib.skyframe.MacOSXFsEventsDiffAwarenessTest --nocache_test_results`
Fixes #1362.
--
Change-Id: I42ceebd8c5a2e0156653b140ca049af45d2e1e80
Reviewed-on: https://bazel-review.googlesource.com/6613
MOS_MIGRATED_REVID=136078777
|
|
|
|
|
|
|
|
|
| |
Tested with the alpine:3.4 Docker image.
--
Change-Id: I8f3e585051988d8fd437ccd69c9c7bd009fd45d2
Reviewed-on: https://bazel-review.googlesource.com/#/c/5790/
MOS_MIGRATED_REVID=135468656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
INFO: From Executing genrule //src/main/native:windows_jni:
C:\tools\msys64\tmp\bazel_7uQBlyR9\out\execroot\bazel>call "C:/Program
Files (x86)/Microsoft Visual Studio 14.0/VC/VCVARSALL.BAT" amd64
windows_error_handling.cc
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\xlocale(341): warning C4530: C++ exception handler used,
but unwind semantics are not enabled. Specify /EHsc
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\exception(359): warning C4577: 'noexcept' used with no
exception handling mode specified; termination on exception is not
guaranteed. Specify /EHsc
windows_file_operations.cc
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\xlocale(341): warning C4530: C++ exception handler used,
but unwind semantics are not enabled. Specify /EHsc
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\exception(359): warning C4577: 'noexcept' used with no
exception handling mode specified; termination on exception is not
guaranteed. Specify /EHsc
windows_processes.cc
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\xlocale(341): warning C4530: C++ exception handler used,
but unwind semantics are not enabled. Specify /EHsc
C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE\iosfwd(343): warning C4577: 'noexcept' used with no
exception handling mode specified; termination on exception is not
guaranteed. Specify /EHsc
--
Change-Id: I6f93a4dbb1be42fa5bea221402fb71a830960cf6
Reviewed-on: https://bazel-review.googlesource.com/#/c/6130
MOS_MIGRATED_REVID=135458066
|
|
|
|
|
|
|
|
|
| |
the Bazel server.
RELNOTES[INC]: --command_port=-1 to use AF_UNIX for client/server communications is not supported anymore.
--
MOS_MIGRATED_REVID=135355673
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Throw an error if Bash-on-Windows is found instead of MSYS bash
2. Introduce BAZEL_VS environment variable
3. Output more information
Fix https://github.com/bazelbuild/bazel/issues/1847
--
Change-Id: Ic4571c6c792d9b81df4cd800b8f19d121cc44c33
Reviewed-on: https://bazel-review.googlesource.com/#/c/6330
MOS_MIGRATED_REVID=134531295
|
|
|
|
|
|
|
|
|
|
| |
Since commit 94d905836c167a21d2321d26c646fde07f5fc522 we no longer need JNI for WindowsFileSystem.isJunction.
This is a partial rollback of commit 4a249b6962d32ed4cfd4165dfdae4a555b00bb69.
Affects https://github.com/bazelbuild/bazel/issues/1680
--
MOS_MIGRATED_REVID=134506403
|
|
|
|
|
|
|
| |
Fixes #1755.
--
MOS_MIGRATED_REVID=132861187
|
|
|
|
|
|
|
| |
The the theory is that the closing the file handle when the process terminates races with the reader threads, and if the closing happens not while a system call is running but between two, nativeReadStream() would return an error.
--
MOS_MIGRATED_REVID=132851092
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/1680
--
MOS_MIGRATED_REVID=132051176
|
|
|
|
|
|
|
| |
WindowsFileSystem.java does not yet use it.
--
MOS_MIGRATED_REVID=132043739
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that we can properly finish reading from it even if it passed them on to a subprocess that did *not* terminate.
The alternative would be to rely on job control.
Fixes #1708. Hopefully.
Tested by running test_cpp 10 times and observing that it doesn't hang.
--
MOS_MIGRATED_REVID=131945117
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change creates a separate file for GetLastErrorString
and updates the BUILD file and windows_jni.dll builder
script.
A subsequent change will add a new source for file
operations implemented in C++, so the BUILD file updates in
this change are necessary preparations for that.
--
MOS_MIGRATED_REVID=131804375
|
|
|
|
|
|
|
| |
I suspect they were overwritten by an eager sed "s,//,#,g" command.
--
MOS_MIGRATED_REVID=131159373
|
|
|
|
|
|
|
| |
Makes #1664 much less acute.
--
MOS_MIGRATED_REVID=130750731
|
|
|
|
|
|
|
|
|
| |
the logical rollback of commit 67ad82a319ff8959e69e774e7c15d3af904ec23d.
RELNOTES[INC]: Bazel supports Unix domain sockets for communication between its client and server again, temporarily, while we diagnose a memory leak.
--
MOS_MIGRATED_REVID=130027009
|