Intellij: Cannot Debug in CLion on Ubuntu: GDB gives timeout error

[dwtj]

The Problem

A CLion/GDB timeout error occurs whenever I try to debug a cc_test target in
a modestly-sized Bazel project with manually set --cxxopt in the .bazelrc
file. Therefore, I can no longer use the CLion debugger on Bazel cc_test
targets in one of my projects.

Here is what the timeout error looks like:

Notice that the project is being recompiled in the window on the left.

Testing Configurations

I've confirmed that this problem exists in at least three configurations:

• Ubuntu 19.04
• CLion v2019.1.3
• Bazel v0.25.2
• bazelbuild/intellij plugin:
  
  
  
  • v2019.05.01.0.3
  
  
  • v2019.05.13.0.2
  
  
  • commit eaeaf473
  
  

(I've also seen this problem with other recent versions of the plugin, but I
haven't recorded exactly which. I describe an older working configuration below
under "Successful Workaround", so the problem probably started sometime since
January.)

Test Project

I've made a simple Bazel project, dwtj/ex_clion_bazel_plugin_gdb_timeout,
to help demonstrate the problem.

This project just contains:

• A .bazelrc file with explicitly set --cxxopt='-std=c++14'
• A trivial cc_test target
• A protobuf target on which the cc_test depends.

(The protobuf dependency is just here to extends compile time long enough to
trigger the timeout. If you can't reproduce the GDB timeout on your system,
try adding some more work for the compiler to do.)

On my system, attempts to debug the hello target always time out 10-15
seconds after the "Debug" toolbar opens. The error message always looks like
this:

Steps to Reproduce

1. Import test project into CLion.
2. Follow the two workarounds which I described in issue #525:
   
   
   
   • select a custom GDB executable (e.g. /usr/bin/gdb)
   
   
   • run chmod u+x gdbserver
   
   
3. Create a CLion Run/Debug Configuration from the "Bazel Command" template
   with target expression //:hello and Bazel command test.
4. Debug this configuration.

On my system, I then observe the following:

1. "Bazel Console" starts "Building debug binary". (See attached log file.)
2. Once compilation completes, the "Debug" Toolbar becomes visible, and its
   "Console" tab starts "Running debug binary". However, this console does not
   just run/debug the binary; it appears to perform the compilation all over
   again. (See attached log file.)
3. About 10-15 seconds after this the red timeout popup appears (pictured
   above).

Workarounds

Unsuccessful Workaround 1: Modify CLion Registry to Lengthen Debugger Timeout

After some googling, I found this JetBrains article: Adjusting GDB start-up
time out value.
However, making this value either small or large made no difference: the
red timeout error happened after about fifteen seconds either way.

Unsuccessful Workaround 2: Lengthen the --test_timeout Argument of the bazel invocation.

I tried modifying the plugin slightly so that the bazel invocations being
run have a much longer --test_timeout. Increasing it from 3600 to 36000000
did not prevent the GDB timeout error.

Successful Workaround: Revert To Old Versions

I've reverted to older releases, specifically, CLion v2018.3.4, Bazel v0.22.0,
and bazelbuild/intellij plugin v2019.01.14.0.5.

Attachments

bazel_console.log
debug_console.log

[epmjohnston]

Has anyone had a chance to look into this?

[dwtj]

This issue appears to still affect the latest releases. I can reproduce this issue in the following configurations:

• Ubuntu 18.04
• CLion 2019.1.4
• Bazel 0.28.0
• bazelbuild/intellij plugin
  
  
  
  • v2019.06.17.0.1
  
  
  • commit c0e8fdfb (committed today)
  
  

Note that I updated the example repo slightly in order to make it buildable by Bazel 0.28.0 (e.g. updated protobuf).

[mattgodbolt]

I'm seeing the same thing on a super-trivial "hello world" project, with CLion 2019.1.4 and plugin 2019.08.19.04

[dwtj]

I've been using a simple workaround for this bug: stop using the .bazelrc file to set --cxxopt; instead set --cxxopt on each target.

Here's my example more explicitly. I wanted all of the C++ code in my project to be compiled as C++17. To do this, I added bazel build --cxxopt='-std=c++17' to my project's .bazelrc file. As I said above, this worked fine with older versions of Bazel+CLion+Plugin, but more recent versions presented the above-described bug.

Fortunately, it turns out that this bug doesn't show up if I just manually add this compiler option to each cc_library target in my project via the copts attribute. Here's an example target declaration:

```
cc_library(
name = "hello",
srcs = ["hello.cc"],
hdrs = ["hello.h"],
copts = ["-std=c++17"],
)
````

[mattgodbolt]

We don't set any cxxopt on the bazel command line, either directly or with .bazelrc. Our bazelrc is:

build --remote_cache=https://elided.for.clarity
build --crosstool_top=@llvm_toolchain//:toolchain
build --workspace_status_command=./ci/print-workspace-status.sh
run --workspace_status_command=./ci/print-workspace-status.sh

# For rules_python
build --incompatible_depset_is_not_iterable=false

# See https://github.com/bazelbuild/rules_docker#known-issues
build --host_force_python=PY2
test --host_force_python=PY2
run --host_force_python=PY2

...in case that jogs someone's memory or thoughts :)

[garethellis0]

I was able to debug tests in CLion 2019.2.2. However I am still observing the same (bad) behavior for cc_binary targets

Observed Behavior

Debugging a cc_test target:

• Setup the target with
  
  
  
  • Bazel Command: test
  
  
  • Bazel Flags: --compilation_mode=dbg
  
  
• Run the test in debug from CLion, am able to set breakpoints and step through code

Debugging a cc_binary target:

• Setup the target with:
  
  
  
  • Bazel Command: run
  
  
  • Bazel Flags: --compilation_mode=dbg
  
  
• Run the test in debug from CLion, eventually get the following error Remote replied unexpectedly to 'vMustReplyEmpty': timeout, and doesn't look like the executable ever runs.

Version information

CLion: 2019.2.2
Platform: Linux 5.0.0-31-generic
Bazel plugin: 9999
Bazel: 0.29.1