Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bazel does not terminate subprocesses on ^C on windows #10573

Closed
Artem-B opened this issue Jan 13, 2020 · 11 comments
Closed

Bazel does not terminate subprocesses on ^C on windows #10573

Artem-B opened this issue Jan 13, 2020 · 11 comments
Assignees
Labels
area-Windows Windows-specific issues and feature requests P2 We'll consider working on this in future. (Assignee optional) team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website type: bug

Comments

@Artem-B
Copy link

Artem-B commented Jan 13, 2020

ATTENTION! Please read and follow:

  • if this is a question about how to build / test / query / deploy using Bazel, or a discussion starter, send it to bazel-discuss@googlegroups.com
  • if this is a bug or feature request, fill the form below as best as you can.

Description of the problem / feature request:

Bazel does not terminate subprocesses on ^C on windows.
When interrupted with ^C the already launched commands continue to run.
If subsequent execution of bazel needs to restart the server, it will silently hang until the old commands have finished.
If one of the old commands is manually killed, then all remaining commands appear to be killed/cleaned up right away.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

BUILD:
genrule(
  name = "long",
  outs = ["foo"],
  cmd = "while true; do sleep 5; echo tick >> $@; done;"
)

Reproduction:

b2e80172 /tmpfs/repro > /tmpfs/bazel200.exe build long -s
INFO: Invocation ID: 042e0282-409d-4ff7-92ee-1629cae57a45
Loading: 
Loading: 0 packages loaded
Analyzing: target //:long (1 packages loaded, 0 targets configured)
INFO: Analyzed target //:long (1 packages loaded, 1 target configured).
INFO: Found 1 target...
[0 / 2] [Prepa] Executing genrule //:long
SUBCOMMAND: # //:long [action 'Executing genrule //:long', configuration: 0c76e4e27246f1cc8c360b2c11de5f1aafe2797237101c507bc86c53960ac843]
cd C:/tools/msys64/home/kbuilder/_bazel_kbuilder/iqatem7v/execroot/__main__
  SET PATH=[...]\
    SET RUNFILES_MANIFEST_ONLY=1
  C:/tools/msys64/usr/bin/bash.exe -c source external/bazel_tools/tools/genrule/genrule-setup.sh; while true; do sleep 5; echo tick >> bazel-out/x64_windows-fastbuild/bin/foo; done;
[1 / 2] Executing genrule //:long; 1s local, remote-cache

Bazel is interrupted here and we're back on the console.
The action continues to run in the background and keeps appending lines to foo:

b2e80172 /tmpfs/repro > ls -l bazel-out/x64_windows-fastbuild/bin/foo
-rw-r--r-- 1 kbuilder None 10 Jan 13 20:14 bazel-out/x64_windows-fastbuild/bin/foo
b2e80172 /tmpfs/repro > wc -l bazel-out/x64_windows-fastbuild/bin/foo
3 bazel-out/x64_windows-fastbuild/bin/foo
b2e80172 /tmpfs/repro > wc -l bazel-out/x64_windows-fastbuild/bin/foo
4 bazel-out/x64_windows-fastbuild/bin/foo
b2e80172 /tmpfs/repro > wc -l bazel-out/x64_windows-fastbuild/bin/foo
5 bazel-out/x64_windows-fastbuild/bin/foo

What operating system are you running Bazel on?

Windows Server 1809

What's the output of bazel info release?

release 2.0.0

Have you found anything relevant by searching the web?

No. Discussed w/ @meteorcloudy who suggested filing a bug.

@meteorcloudy meteorcloudy added P2 We'll consider working on this in future. (Assignee optional) area-Windows Windows-specific issues and feature requests type: bug labels Jan 14, 2020
@meteorcloudy
Copy link
Member

/cc @laszlocsomor

@laszlocsomor
Copy link
Contributor

laszlocsomor commented Jan 14, 2020

I can repro when running Bazel from MSYS, but not when running from cmd.exe
@Artem-B , are you running under MSYS or WSL, or are you running it from cmd.exe?

@Artem-B
Copy link
Author

Artem-B commented Jan 14, 2020

bazel is launched from an msys2 shell, though the shell itself is launched from a nested combination of msys2 bash scripts & .bat files executed by cmd /c.

Are you saying that things should work better if I do cmd /c bazel build long? I've just tried that and things appear to be worse. On ^C cmd itself does terminate, but bazel continues to be running and so does the genrule loop it launched.

@laszlocsomor
Copy link
Contributor

I mean if you run bazel build long from an interactive cmd shell, then ^C works as expected.

Thanks for the clarification, I'll investigate more.

@laszlocsomor
Copy link
Contributor

laszlocsomor commented Jan 15, 2020

This seems to be an ancient MSYS2/MingW bug. Apparently they terminate programs on Ctrl+C instead of allowing them to handle the signal: https://stackoverflow.com/a/52657873/7778502

Open bugs threads from 2016 and 2003 (!):

This is why Ctrl+C will terminate the client and its children, but not the server nor the server's children (which bash and sleep are).

One workaround people suggest is to run Bazel under winpty: https://stackoverflow.com/a/48323689/7778502 . (Never mind that it talks about Git Bash, because that is actually MSYS under the cover.) I never tried this program though.

Another workaround is to use --batch mode, because then the server is a child of the client and terminating the client will also kill the server... but this is abrupt termination, so the processes may leave stale state behind. (Also, --batch mode means the client starts a new server, so incremental builds are slower.)

Or run Bazel from cmd.exe, everything works nicely there, even in --nobatch mode.

@laszlocsomor
Copy link
Contributor

Summary: we can't fix this bug.
I will update the website not to recommend running under MSYS and also link to this bug.

bazel-io pushed a commit that referenced this issue Jan 15, 2020
Update the "Using Bazel on Windows" page to
discourage running Bazel from MSYS2 Bash.

See #10573

RELNOTES: Windows: we now discourage running Bazel from MSYS2 because of a newly found bug (#10573)
PiperOrigin-RevId: 289833002
meteorcloudy pushed a commit to meteorcloudy/bazel that referenced this issue Feb 10, 2020
Baseline: 9807e50

Cherry picks:

   + 217c918:
     Swith to meteorcloudy/bazel
   + 16b89e2:
     Remove git notes from release process
   + 97869c1:
     Add blabla2

Incompatible changes:

  - The following attributes of CcToolchainProvider, which formerly
    were
    accessible both as fields (x.f) and as methods (x.f()), are now
    only fields:
  - The --[no]incompatible_windows_bashless_run_command flag is no
    longer supported. It was flipped in Bazel 1.0
  - The --[no]incompatible_windows_native_test_wrapper flag is no
    longer supported. It was flipped in Bazel 1.0

New features:

  - Similar to the
    [.bazelignore](https://docs.bazel.build/versions/master/guide.html
    #.bazelignore) in the main repository, a `.bazelignore` file in
    external repository will cause the specified directories to be
    ignored by Bazel. Bazel won't try to identify any packages under
    the directories, but the files can still be referenced in other
    BUILD files.
  - bazelignore files now support line comments, e.g. "# this is a
    comment"

Important changes:

  - Experimental support for d8 merger is now available for use using
    --define=android_dexmerger_tool=d8_dexmerger.
  - Critical path run time should not have a longer run time than
    total execution run time.
  - Remove "please do not import" warning for cc rules.
  - x.f() is now equivalent to y=x.f; y(). That is, x.f should return
    the same
    attribute value regardless of whether it is accessed as a field
    or called
    like a method. Any arguments to the call are evaluated after the
    x.f operation.
  - Add desugaring support for RoleManager#addRoleHolderAsUser
  - Adds ctx.target_platform_has_constraint to allow rules to check
    the target platform's constraints.
  - Critical path run time should not have a longer run time than
    total execution run time.
  - Post new ConvenienceSymlinksIdentifiedEvent to the
    BuildEventProtocol when
    --experimental_convenience_symlinks_bep_event is enabled.
  - Keyword-only arguments are now allowed:
        def foo(a, *, k): pass
        def foo(a, *b, k): pass
      where k can be specified only by keyword:
        foo(5, k=6)
  - Generated Go protobufs now depend on //net/proto2/go:protodeps in
    addition to //net/proto2/go:proto
  - cquery 'somepath' returns more reliable results when the
    dep has a different configuration than the parent. To get a
    result for
    `somepath(//foo, //bar`) where //bar isn't in the top-level
    configuration,
    run your query with `--universe_scope=//foo`. See cquery docs for
    details.
  - Consistent target naming style in example target names.
  - cquery's config() now supports arbitrary configurations.
  - The flag --incompatible_disallow_dict_lookup_unhashable_keys is
    removed.
  - Include target label in Python version error message.
  - The flag --incompatible_remap_main_repo is removed.
  - Windows: we now discourage running Bazel from MSYS2 because of a
    newly found bug (bazelbuild#10573)
  - Reduced the packaging time (`package-bazel.sh`) for the
    `//src:bazel-dev` Bazel development build target from 14s to 6s.
    Use `//src:bazel-dev` if you're iterating rapidly on a local
    Bazel changes, and use `//src:bazel --compilation_mode=opt` for
    release builds.
  - cquery: "//foo:bar" now means "all configured targets with label
    //foo:bar" instead of "choose an arbitrary configured target with
    label //foo:bar". See cquery docs for details.
  - WORKSPACE and BUILD.bazel files of http_archive repositories can
    now be patched using the "patch_cmds" and "patches" attributes.
  - Actions with "parse" on the critical path should no longer finish
    in the future.
  - Flags that affect external repositories like
    "--override_repository" can now be addressed in bazelrc files
    using the "common" command, without causing commands like "bazel
    shutdown" to fail.
  - The flag --incompatible_disallow_unverified_http_downloads is
    removed.
  - Create the incompatibleApplicableLicenses flag.
    We plan to flip this from false to true in Bazel 4.x.
    Implementation to follow.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.

This release contains contributions from many people at Google, as well as Adam Liddell, Alessandro Patti, Alex Kirchhoff, aman, Andreas Herrmann, Benjamin Peterson, Benjamin Peterson, Bor Kae Hwang, Brian Silverman, David Ostrovsky, Elliotte Rusty Harold, Emran BatmanGhelich, George Gensure, Greg Estren, Jeff Palm, John Millikin, Jonathan Beverly, Mark Nevill, Michael McLoughlin, nikola-sh, Nikolay Shelukhin, Patrick Niklaus, Peter, Philipp Wollermann, Ryan Beasley, Shin Yamamoto, Yannic Bonenberger, Yannic, Yen-Chi Chen.
meteorcloudy pushed a commit to meteorcloudy/bazel that referenced this issue Feb 10, 2020
Baseline: ef34fe6

Cherry picks:

   + 3983e21:
     Swith to meteorcloudy/bazel
   + 2c16f0dc3dc62d2e567ffa5bb34d3ffdd99a8b57:
     Remove git notes from release process
   + 08743313e709e8d1d590fa471ef1ca97a5a84d19:
     Add blabla2

Incompatible changes:

  - The following attributes of CcToolchainProvider, which formerly
    were
    accessible both as fields (x.f) and as methods (x.f()), are now
    only fields:
  - The --[no]incompatible_windows_bashless_run_command flag is no
    longer supported. It was flipped in Bazel 1.0
  - The --[no]incompatible_windows_native_test_wrapper flag is no
    longer supported. It was flipped in Bazel 1.0

New features:

  - Similar to the
    [.bazelignore](https://docs.bazel.build/versions/master/guide.html
    #.bazelignore) in the main repository, a `.bazelignore` file in
    external repository will cause the specified directories to be
    ignored by Bazel. Bazel won't try to identify any packages under
    the directories, but the files can still be referenced in other
    BUILD files.
  - bazelignore files now support line comments, e.g. "# this is a
    comment"

Important changes:

  - Experimental support for d8 merger is now available for use using
    --define=android_dexmerger_tool=d8_dexmerger.
  - Critical path run time should not have a longer run time than
    total execution run time.
  - Remove "please do not import" warning for cc rules.
  - x.f() is now equivalent to y=x.f; y(). That is, x.f should return
    the same
    attribute value regardless of whether it is accessed as a field
    or called
    like a method. Any arguments to the call are evaluated after the
    x.f operation.
  - Add desugaring support for RoleManager#addRoleHolderAsUser
  - Adds ctx.target_platform_has_constraint to allow rules to check
    the target platform's constraints.
  - Critical path run time should not have a longer run time than
    total execution run time.
  - Post new ConvenienceSymlinksIdentifiedEvent to the
    BuildEventProtocol when
    --experimental_convenience_symlinks_bep_event is enabled.
  - Keyword-only arguments are now allowed:
        def foo(a, *, k): pass
        def foo(a, *b, k): pass
      where k can be specified only by keyword:
        foo(5, k=6)
  - Generated Go protobufs now depend on //net/proto2/go:protodeps in
    addition to //net/proto2/go:proto
  - cquery 'somepath' returns more reliable results when the
    dep has a different configuration than the parent. To get a
    result for
    `somepath(//foo, //bar`) where //bar isn't in the top-level
    configuration,
    run your query with `--universe_scope=//foo`. See cquery docs for
    details.
  - Consistent target naming style in example target names.
  - cquery's config() now supports arbitrary configurations.
  - The flag --incompatible_disallow_dict_lookup_unhashable_keys is
    removed.
  - Include target label in Python version error message.
  - The flag --incompatible_remap_main_repo is removed.
  - Windows: we now discourage running Bazel from MSYS2 because of a
    newly found bug (bazelbuild#10573)
  - Reduced the packaging time (`package-bazel.sh`) for the
    `//src:bazel-dev` Bazel development build target from 14s to 6s.
    Use `//src:bazel-dev` if you're iterating rapidly on a local
    Bazel changes, and use `//src:bazel --compilation_mode=opt` for
    release builds.
  - cquery: "//foo:bar" now means "all configured targets with label
    //foo:bar" instead of "choose an arbitrary configured target with
    label //foo:bar". See cquery docs for details.
  - WORKSPACE and BUILD.bazel files of http_archive repositories can
    now be patched using the "patch_cmds" and "patches" attributes.
  - Actions with "parse" on the critical path should no longer finish
    in the future.
  - Flags that affect external repositories like
    "--override_repository" can now be addressed in bazelrc files
    using the "common" command, without causing commands like "bazel
    shutdown" to fail.
  - The flag --incompatible_disallow_unverified_http_downloads is
    removed.
  - Create the incompatibleApplicableLicenses flag.
    We plan to flip this from false to true in Bazel 4.x.
    Implementation to follow.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.

This release contains contributions from many people at Google, as well as Adam Liddell, Alessandro Patti, Alex Kirchhoff, aman, Andreas Herrmann, Benjamin Peterson, Benjamin Peterson, Bor Kae Hwang, Brian Silverman, David Ostrovsky, Elliotte Rusty Harold, Emran BatmanGhelich, George Gensure, Greg Estren, Jeff Palm, John Millikin, Jonathan Beverly, Mark Nevill, Michael McLoughlin, nikola-sh, Nikolay Shelukhin, Patrick Niklaus, Peter, Philipp Wollermann, Ryan Beasley, Shin Yamamoto, Yannic Bonenberger, Yannic, Yen-Chi Chen.
meteorcloudy pushed a commit to meteorcloudy/bazel that referenced this issue Feb 10, 2020
Baseline: 9807e50

Cherry picks:

   + 3983e21:
     Swith to meteorcloudy/bazel
   + 8d29820:
     Remove git notes from release process
   + 3e83ee1:
     Add blabla2

Incompatible changes:

  - The following attributes of CcToolchainProvider, which formerly
    were
    accessible both as fields (x.f) and as methods (x.f()), are now
    only fields:
  - The --[no]incompatible_windows_bashless_run_command flag is no
    longer supported. It was flipped in Bazel 1.0
  - The --[no]incompatible_windows_native_test_wrapper flag is no
    longer supported. It was flipped in Bazel 1.0

New features:

  - Similar to the
    [.bazelignore](https://docs.bazel.build/versions/master/guide.html
    #.bazelignore) in the main repository, a `.bazelignore` file in
    external repository will cause the specified directories to be
    ignored by Bazel. Bazel won't try to identify any packages under
    the directories, but the files can still be referenced in other
    BUILD files.
  - bazelignore files now support line comments, e.g. "# this is a
    comment"

Important changes:

  - Experimental support for d8 merger is now available for use using
    --define=android_dexmerger_tool=d8_dexmerger.
  - Critical path run time should not have a longer run time than
    total execution run time.
  - Remove "please do not import" warning for cc rules.
  - x.f() is now equivalent to y=x.f; y(). That is, x.f should return
    the same
    attribute value regardless of whether it is accessed as a field
    or called
    like a method. Any arguments to the call are evaluated after the
    x.f operation.
  - Add desugaring support for RoleManager#addRoleHolderAsUser
  - Adds ctx.target_platform_has_constraint to allow rules to check
    the target platform's constraints.
  - Critical path run time should not have a longer run time than
    total execution run time.
  - Post new ConvenienceSymlinksIdentifiedEvent to the
    BuildEventProtocol when
    --experimental_convenience_symlinks_bep_event is enabled.
  - Keyword-only arguments are now allowed:
        def foo(a, *, k): pass
        def foo(a, *b, k): pass
      where k can be specified only by keyword:
        foo(5, k=6)
  - Generated Go protobufs now depend on //net/proto2/go:protodeps in
    addition to //net/proto2/go:proto
  - cquery 'somepath' returns more reliable results when the
    dep has a different configuration than the parent. To get a
    result for
    `somepath(//foo, //bar`) where //bar isn't in the top-level
    configuration,
    run your query with `--universe_scope=//foo`. See cquery docs for
    details.
  - Consistent target naming style in example target names.
  - cquery's config() now supports arbitrary configurations.
  - The flag --incompatible_disallow_dict_lookup_unhashable_keys is
    removed.
  - Include target label in Python version error message.
  - The flag --incompatible_remap_main_repo is removed.
  - Windows: we now discourage running Bazel from MSYS2 because of a
    newly found bug (bazelbuild#10573)
  - Reduced the packaging time (`package-bazel.sh`) for the
    `//src:bazel-dev` Bazel development build target from 14s to 6s.
    Use `//src:bazel-dev` if you're iterating rapidly on a local
    Bazel changes, and use `//src:bazel --compilation_mode=opt` for
    release builds.
  - cquery: "//foo:bar" now means "all configured targets with label
    //foo:bar" instead of "choose an arbitrary configured target with
    label //foo:bar". See cquery docs for details.
  - WORKSPACE and BUILD.bazel files of http_archive repositories can
    now be patched using the "patch_cmds" and "patches" attributes.
  - Actions with "parse" on the critical path should no longer finish
    in the future.
  - Flags that affect external repositories like
    "--override_repository" can now be addressed in bazelrc files
    using the "common" command, without causing commands like "bazel
    shutdown" to fail.
  - The flag --incompatible_disallow_unverified_http_downloads is
    removed.
  - Create the incompatibleApplicableLicenses flag.
    We plan to flip this from false to true in Bazel 4.x.
    Implementation to follow.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.

This release contains contributions from many people at Google, as well as Adam Liddell, Alessandro Patti, Alex Kirchhoff, aman, Andreas Herrmann, Benjamin Peterson, Benjamin Peterson, Bor Kae Hwang, Brian Silverman, David Ostrovsky, Elliotte Rusty Harold, Emran BatmanGhelich, George Gensure, Greg Estren, Jeff Palm, John Millikin, Jonathan Beverly, Mark Nevill, Michael McLoughlin, nikola-sh, Nikolay Shelukhin, Patrick Niklaus, Peter, Philipp Wollermann, Ryan Beasley, Shin Yamamoto, Yannic Bonenberger, Yannic, Yen-Chi Chen.
meteorcloudy pushed a commit to meteorcloudy/bazel that referenced this issue Feb 10, 2020
Baseline: 9807e50

Cherry picks:

   + 3983e21:
     Swith to meteorcloudy/bazel
   + a9d2d07:
     Remove git notes from release process
   + 8c1b17b:
     Add blabla2

Incompatible changes:

  - The following attributes of CcToolchainProvider, which formerly
    were
    accessible both as fields (x.f) and as methods (x.f()), are now
    only fields:
  - The --[no]incompatible_windows_bashless_run_command flag is no
    longer supported. It was flipped in Bazel 1.0
  - The --[no]incompatible_windows_native_test_wrapper flag is no
    longer supported. It was flipped in Bazel 1.0

New features:

  - Similar to the
    [.bazelignore](https://docs.bazel.build/versions/master/guide.html
    #.bazelignore) in the main repository, a `.bazelignore` file in
    external repository will cause the specified directories to be
    ignored by Bazel. Bazel won't try to identify any packages under
    the directories, but the files can still be referenced in other
    BUILD files.
  - bazelignore files now support line comments, e.g. "# this is a
    comment"

Important changes:

  - Experimental support for d8 merger is now available for use using
    --define=android_dexmerger_tool=d8_dexmerger.
  - Critical path run time should not have a longer run time than
    total execution run time.
  - Remove "please do not import" warning for cc rules.
  - x.f() is now equivalent to y=x.f; y(). That is, x.f should return
    the same
    attribute value regardless of whether it is accessed as a field
    or called
    like a method. Any arguments to the call are evaluated after the
    x.f operation.
  - Add desugaring support for RoleManager#addRoleHolderAsUser
  - Adds ctx.target_platform_has_constraint to allow rules to check
    the target platform's constraints.
  - Critical path run time should not have a longer run time than
    total execution run time.
  - Post new ConvenienceSymlinksIdentifiedEvent to the
    BuildEventProtocol when
    --experimental_convenience_symlinks_bep_event is enabled.
  - Keyword-only arguments are now allowed:
        def foo(a, *, k): pass
        def foo(a, *b, k): pass
      where k can be specified only by keyword:
        foo(5, k=6)
  - Generated Go protobufs now depend on //net/proto2/go:protodeps in
    addition to //net/proto2/go:proto
  - cquery 'somepath' returns more reliable results when the
    dep has a different configuration than the parent. To get a
    result for
    `somepath(//foo, //bar`) where //bar isn't in the top-level
    configuration,
    run your query with `--universe_scope=//foo`. See cquery docs for
    details.
  - Consistent target naming style in example target names.
  - cquery's config() now supports arbitrary configurations.
  - The flag --incompatible_disallow_dict_lookup_unhashable_keys is
    removed.
  - Include target label in Python version error message.
  - The flag --incompatible_remap_main_repo is removed.
  - Windows: we now discourage running Bazel from MSYS2 because of a
    newly found bug (bazelbuild#10573)
  - Reduced the packaging time (`package-bazel.sh`) for the
    `//src:bazel-dev` Bazel development build target from 14s to 6s.
    Use `//src:bazel-dev` if you're iterating rapidly on a local
    Bazel changes, and use `//src:bazel --compilation_mode=opt` for
    release builds.
  - cquery: "//foo:bar" now means "all configured targets with label
    //foo:bar" instead of "choose an arbitrary configured target with
    label //foo:bar". See cquery docs for details.
  - WORKSPACE and BUILD.bazel files of http_archive repositories can
    now be patched using the "patch_cmds" and "patches" attributes.
  - Actions with "parse" on the critical path should no longer finish
    in the future.
  - Flags that affect external repositories like
    "--override_repository" can now be addressed in bazelrc files
    using the "common" command, without causing commands like "bazel
    shutdown" to fail.
  - The flag --incompatible_disallow_unverified_http_downloads is
    removed.
  - Create the incompatibleApplicableLicenses flag.
    We plan to flip this from false to true in Bazel 4.x.
    Implementation to follow.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.

This release contains contributions from many people at Google, as well as Adam Liddell, Alessandro Patti, Alex Kirchhoff, aman, Andreas Herrmann, Benjamin Peterson, Benjamin Peterson, Bor Kae Hwang, Brian Silverman, David Ostrovsky, Elliotte Rusty Harold, Emran BatmanGhelich, George Gensure, Greg Estren, Jeff Palm, John Millikin, Jonathan Beverly, Mark Nevill, Michael McLoughlin, nikola-sh, Nikolay Shelukhin, Patrick Niklaus, Peter, Philipp Wollermann, Ryan Beasley, Shin Yamamoto, Yannic Bonenberger, Yannic, Yen-Chi Chen.
@konste
Copy link
Contributor

konste commented Feb 18, 2020

Is it known if the bug applies to both MSYS and WSL? If WSL is also affected is it Ok to have it installed as long as the actual build is run from CMD.EXE? Because it is really hard to design Windows build without relying on WSL.

@meteorcloudy
Copy link
Member

@konste We never tested Bazel on Windows with WSL. Are you using Bazel with WSL? If so, can you try to reproduce this issue in WSL?

@tdm20
Copy link

tdm20 commented Feb 19, 2020

I have WSL (Ubuntu) and MSYS2 installed.
Using an MSYS2 bash exhibits the behavior in this bug (Ctrl-C does not kill the server, I had to kill java.exe).

Using windows bash works fine (Ctrl-C stops the bazel server correctly)
Using WSL Ubuntu bash works fine (ditto).

I am using Bazel 2.1.0 on Windows 10

@meteorcloudy
Copy link
Member

@tdm20 That's great to hear! Thank you!

bazel-io pushed a commit that referenced this issue Mar 3, 2020
Baseline: 78055ef

Incompatible changes:

  - The --[no]incompatible_windows_bashless_run_command flag is no
    longer supported. It was flipped in Bazel 1.0
  - The --[no]incompatible_windows_native_test_wrapper flag is no
    longer supported. It was flipped in Bazel 1.0

Important changes:

  - Consistent target naming style in example target names.
  - cquery's config() now supports arbitrary configurations.
  - The flag --incompatible_disallow_dict_lookup_unhashable_keys is
    removed.
  - Include target label in Python version error message.
  - The flag --incompatible_remap_main_repo is removed.
  - Windows: we now discourage running Bazel from MSYS2 because of a
    newly found bug (#10573)
  - Reduced the packaging time (`package-bazel.sh`) for the
    `//src:bazel-dev` Bazel development build target from 14s to 6s.
    Use `//src:bazel-dev` if you're iterating rapidly on a local
    Bazel changes, and use `//src:bazel --compilation_mode=opt` for
    release builds.
  - cquery: "//foo:bar" now means "all configured targets with label
    //foo:bar" instead of "choose an arbitrary configured target with
    label //foo:bar". See cquery docs for details.
  - WORKSPACE and BUILD.bazel files of http_archive repositories can
    now be patched using the "patch_cmds" and "patches" attributes.
  - Actions with "parse" on the critical path should no longer finish
    in the future.
  - Flags that affect external repositories like
    "--override_repository" can now be addressed in bazelrc files
    using the "common" command, without causing commands like "bazel
    shutdown" to fail.
  - The flag --incompatible_disallow_unverified_http_downloads is
    removed.
  - Create the incompatibleApplicableLicenses flag.
    We plan to flip this from false to true in Bazel 4.x.
    Implementation to follow.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.
  - The --starlark_cpu_profile=<file> flag writes a profile in
    pprof format containing a statistical summary of CPU usage
    by all Starlark execution during the bazel command. Use it
    to identify slow Starlark functions in loading and analysis.
  - --ram_utilization_factor will be deprecated. Please use
    --local_ram_resources=HOST_RAM*<float>
  - Docs: glob() documentation is rewritten, and now it points out a
    pitfall of rules shadowing glob-matched files.

This release contains contributions from many people at Google, as well as Alessandro Patti, Alex Kirchhoff, aman, Artur Dryomov, Benjamin Peterson, Benjamin Peterson, David Ostrovsky, Elliotte Rusty Harold, Eric Klein, George Chiramel, George Gensure, Guillaume Bouchard, Hui-Zhi, John Millikin, Jonathan Springer, Laurent Le Brun, Michael McLoughlin, nikola-sh, Nikolaus Wittenstein, Nikolay Shelukhin, Yannic Bonenberger, Yannic.
AlessandroPatti pushed a commit to uber-common/bazel that referenced this issue Mar 3, 2020
Baseline: 78055ef

Incompatible changes:

  - The --[no]incompatible_windows_bashless_run_command flag is no
    longer supported. It was flipped in Bazel 1.0
  - The --[no]incompatible_windows_native_test_wrapper flag is no
    longer supported. It was flipped in Bazel 1.0

Important changes:

  - Consistent target naming style in example target names.
  - cquery's config() now supports arbitrary configurations.
  - The flag --incompatible_disallow_dict_lookup_unhashable_keys is
    removed.
  - Include target label in Python version error message.
  - The flag --incompatible_remap_main_repo is removed.
  - Windows: we now discourage running Bazel from MSYS2 because of a
    newly found bug (bazelbuild#10573)
  - Reduced the packaging time (`package-bazel.sh`) for the
    `//src:bazel-dev` Bazel development build target from 14s to 6s.
    Use `//src:bazel-dev` if you're iterating rapidly on a local
    Bazel changes, and use `//src:bazel --compilation_mode=opt` for
    release builds.
  - cquery: "//foo:bar" now means "all configured targets with label
    //foo:bar" instead of "choose an arbitrary configured target with
    label //foo:bar". See cquery docs for details.
  - WORKSPACE and BUILD.bazel files of http_archive repositories can
    now be patched using the "patch_cmds" and "patches" attributes.
  - Actions with "parse" on the critical path should no longer finish
    in the future.
  - Flags that affect external repositories like
    "--override_repository" can now be addressed in bazelrc files
    using the "common" command, without causing commands like "bazel
    shutdown" to fail.
  - The flag --incompatible_disallow_unverified_http_downloads is
    removed.
  - Create the incompatibleApplicableLicenses flag.
    We plan to flip this from false to true in Bazel 4.x.
    Implementation to follow.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.
  - Treat .cu and .cl files as C++ source. CUDA or OpenCL are not
    natively supported and will require custom flags to compile with
    e.g. clang.
  - The --starlark_cpu_profile=<file> flag writes a profile in
    pprof format containing a statistical summary of CPU usage
    by all Starlark execution during the bazel command. Use it
    to identify slow Starlark functions in loading and analysis.
  - --ram_utilization_factor will be deprecated. Please use
    --local_ram_resources=HOST_RAM*<float>
  - Docs: glob() documentation is rewritten, and now it points out a
    pitfall of rules shadowing glob-matched files.

This release contains contributions from many people at Google, as well as Alessandro Patti, Alex Kirchhoff, aman, Artur Dryomov, Benjamin Peterson, Benjamin Peterson, David Ostrovsky, Elliotte Rusty Harold, Eric Klein, George Chiramel, George Gensure, Guillaume Bouchard, Hui-Zhi, John Millikin, Jonathan Springer, Laurent Le Brun, Michael McLoughlin, nikola-sh, Nikolaus Wittenstein, Nikolay Shelukhin, Yannic Bonenberger, Yannic.
@philwo philwo added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Jun 15, 2020
@jdpipe
Copy link

jdpipe commented Feb 14, 2022

I've just installed Bazel using Scoop, and then export PATH=$PATH:/c/Users/pye/scoop/shims. I found that from MSYS2 Bash (mintty), Bazel does run, and certainly ctrl+C works fine to interrupt the build. So the reasons that are specified here are no longer accurate:

As of 2020-01-15, do not run Bazel from bash – either from MSYS2 shell, or Git Bash, or Cygwin, or any other Bash variant. While Bazel may work for most use cases, some things are broken, like interrupting the build with Ctrl+C from MSYS2). Also, if you choose to run under MSYS2, you need to disable MSYS2’s automatic path conversion, otherwise MSYS will convert command line arguments that look like Unix paths (e.g. //foo:bar) into Windows paths. See this StackOverflow answer for details.

Nevertheless, there are other strange things happening. Bazel (attempting to build tensorflow) seems to have taken it into its mind to download LLVM (but it fails, 'Loading: 0 packages loaded' keeps coming up). This tool seems to be trying to be extremely powerful, but it doesn't work, and a simple error message ("unable to find a suitable compiler") or ("building under MSYS2 is not supported") would have been better I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Windows Windows-specific issues and feature requests P2 We'll consider working on this in future. (Assignee optional) team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website type: bug
Projects
None yet
Development

No branches or pull requests

7 participants