-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Resizing the terminal kills bazel run
tests
#17215
Comments
We probably have to handle the signal here: https://cs.opensource.google/bazel/bazel/+/2f9c7d60ea676f9f8e929b20a3ff74e786995c91:src/main/cpp/blaze_util_posix.cc;l=134 |
Previously, after two window resize events we would stop waiting for the child process - this makes sense for other signals but not for SIGWINCH. Fixes bazelbuild#17215
Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 30 days. It will be closed in the next 7 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". |
Not stale. |
…rectly. Previously, after two window resize events we would stop waiting for the child process. `wait` is interrupted by any trapped signal (and we trap all signals), so we need to call it in a loop until the child really exited. Fixes bazelbuild#17215 Closes bazelbuild#17301. PiperOrigin-RevId: 514395755 Change-Id: Ifb763a55d53f230cde8b1ca77761d94ea6e43e1f
…rectly. (#17760) Previously, after two window resize events we would stop waiting for the child process. `wait` is interrupted by any trapped signal (and we trap all signals), so we need to call it in a loop until the child really exited. Fixes #17215 Closes #17301. PiperOrigin-RevId: 514395755 Change-Id: Ifb763a55d53f230cde8b1ca77761d94ea6e43e1f Co-authored-by: Tobias Werth <[email protected]>
…rectly. Previously, after two window resize events we would stop waiting for the child process. `wait` is interrupted by any trapped signal (and we trap all signals), so we need to call it in a loop until the child really exited. Fixes bazelbuild#17215 Closes bazelbuild#17301. PiperOrigin-RevId: 514395755 Change-Id: Ifb763a55d53f230cde8b1ca77761d94ea6e43e1f
Description of the bug:
Resizing the terminal while running
bazel run TARGET
whenTARGET
is a test rule makes the bazel process exit with code 156. This doesn't occur whenTARGET
is an executable but non-test rule.I can reproduce this on Linux and macOS with Kitty, Alacritty and WezTerm terminal emulators with terms
xterm-kitty
andxterm-256color
. Whether$PAGER
is set or not doesn't seem to make a difference.recording.mp4
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
I put together a MWE here: https://gist.github.com/the-mikedavis/6b34a7f445a30fb34331d1fa19b89201
Most minimally, a directory with an empty
WORKSPACE
file, aBUILD
file with contents like so:and
defs.bzl
:Altogether the directory should look like so:
Run
bazel run //:hello
in this directory. Once you see the "...", resize the terminal. For resizing done through a window manager, you need to resize the terminal twice: the first resize doesn't kill bazel. Thebazel
process should exit with code 156.Which operating system are you running Bazel on?
Linux, macOS
What is the output of
bazel info release
?release 6.0.0
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD
?No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: