Bazel run for a test target under GDB exits immediately

[AdamDorwart]

Description of the problem / feature request:

When executing bazel run --run_under=gdb with the new direct_run feature seems to work as expected for *_binary targets. However if you try to bazel run ... a *_test target it doesn't appear to be redirecting stdin as expected.

Note: This wrapper script is a work around
gdb_tty.sh

gdb "$@" < /dev/tty

and then use bazel run --run_under=gdb_tty.sh ...

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

So for instance

$ bazel run --run_under=gdb //my_binary_target
INFO: Analysed target //my_binary_target (0 packages loaded).
INFO: Found 1 target...
Target //my_binary_target up-to-date:
  bazel-bin/my_binary_target
INFO: Elapsed time: 0.379s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/user/.cache/bazel/_bazel_user/626a240429aac10b2a1fee0b81ed3e1c/execroot/repo/bazel-out/k8-opt/bin/my_binary_target...done.
(gdb) 

Works great. In contrast, when trying to run a test target:

$ bazel run --run_under=gdb //my_test_target
INFO: Analysed target //my_test_target (0 packages loaded).
INFO: Found 1 target...
Target //my_test_target up-to-date:
  bazel-bin/my_test_target
INFO: Elapsed time: 0.386s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Running command line: external/bazel_tools/tools/test/test-setup.sh /bin/bash -c '"$@"' /bin/sh gdb exterINFO: Build completed successfully, 1 total action
exec ${PAGER:-/usr/bin/less} "$0" || exit 1
Executing tests from //my_test_target
-----------------------------------------------------------------------------
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from my_test_target...done.
(gdb) quit

And ends immediately.

What operating system are you running Bazel on?

Ubuntu 16.04

What's the output of bazel info release?

release 0.16.1

Have you found anything relevant by searching the web?

#2815
https://groups.google.com/forum/#!topic/bazel-discuss/Mu95dnuA2MQ

[lberki]

This is because the test is actually run as a background process for various interesting reasons (/cc @ola-rozenfeld):

https://github.com/bazelbuild/bazel/blob/master/tools/test/test-setup.sh#L264

Given that you have workaround, I'd not spend too much time fixing this -- it's conceivable that we could do some shell magic to do so, but we do enough shell magic there already so I'm reluctant to add more.

[AdamDorwart]

Is there no way to differentiate when the test target is executed with bazel run and then use the same direct mode behavior? Intuitively it makes sense that bazel run for a test target would just run the binary similar to how any other *_binary target does. Understandably simpler said then done since the test environment is more controlled than a normal binary.

Maybe it would be acceptable to just mimic the normal run environment for test targets?

[lberki]

Jain, as they say in German... sure, it's possible, but some people expect tests being run as a test under bazel run, so I'd have to add a knob and we are rapidly approaching a thousand command line options already.

[jin]

@lberki which is the subteam that should own this?

[lberki]

Put this down as "local exec" for... well, lack of a better one.

[jmmv]

I gave this a try and noticed that this has become "worse" now, as the test execution will now stall under gdb and not accept any input. Ctrl+Z causes the test to be killed though.

[EricBayer]

I just ran into this myself (not using --run_under=gdb). I have a fairly complex rule that calls existing tools that I'd like to work for test and for several complex interactive debugging features (currently chosen via command line options)... The only work around I found for now is to make a macro front end to duplicate this once with test = True and once with executable = True, both using the same implementation but with name set to have an additional suffix.) I'm less than thrilled with doubling the build rules and my end users having to know that the target name is something different when debugging.

The command line option approach, mentioned above, seems wrong to my mind as it makes the person executing the bazel command be in charge of understanding the difference. I'd much rather have the intent encoded in the build files. Not to mention your aversion (totally understandable) to adding to the ever increasing list. I have two potential suggestions:

1. The engine upon seeing that both attributes on the rule are actually set in Starlark (test = True and executable = True ), lets it run interactively, but still test through the existing magic.
2. The rule has some additional flag like run_interactive = True that lets it run interactively, but still test through the existing magic.

I think both would be a lot cleaner and a better model. Any comments?

[EricCousineau-TRI]

Re-encountered this here:
https://github.com/EricCousineau-TRI/repro/blob/24ef5b73a/bug/bazel_stdin_tty_python/README.md

But yeah, just running test binary via ./bazel-bin also works A-OK.

\cc @jwnimmer-tri - prolly something you already knew about bazel run w/ tests

[github-actions]

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 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!