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

CLion Fails to Debug cc_binary target on macOS #494

Closed
dwtj opened this issue Jan 12, 2019 · 26 comments · Fixed by #843
Closed

CLion Fails to Debug cc_binary target on macOS #494

dwtj opened this issue Jan 12, 2019 · 26 comments · Fixed by #843
Labels
lang: c++ C++ rules integration os: macos macOS support product: CLion CLion plugin topic: debugging Issues related to debugging type: bug

Comments

@dwtj
Copy link

dwtj commented Jan 12, 2019

The Problem

I've written a hello world cc_binary target, but my attempts to debug it from within CLion fail.

I've created a repository, dwtj/clwb-bugs-example, to demonstrate the problem. It includes analogous CMake and Bazel builds of this program.

When I use CLion+CMake, I can debug hello_world just fine, but when I try to debug it with CLion+Bazel, I get a red popup error. The image below shows these two projects side-by-side:

cmake_vs_bazel-debugger_executable_not_specified

The red popup error says:

Error running 'Bazel run :hello_world':
Debugger executable not specified Configure

Here, "Configure" is a link to CLion's "Preferences" > "Build, Execution, Deployment" > "Toolchains". Here's what that looks like for me:

clion_toolchains_default

There are three choices in the "Debugger" drop-down menu:

  • Bundled LLDB
  • Bundled GDB
  • Custom GDB Executable

Note that there doesn't seem to be a "Custom LLDB" option. For varying reasons, all of these options fail in my CLion+Bazel project.

Bundled LLDB

As described above, "Bundled LLDB" seems to work fine in CLion+CMake, but it fails with the red popup error in CLion+Bazel.

Bundled GDB

When I chose this option, I get "a file format not recognized error." This happens for both CLion+CMake and CLion+Bazel.

I guess this makes sense, since my Clang/LLVM toolchain is building the program in either case, and evidently GDB won't work on a Clang-built executable. Here's the image:

cmake_vs_bazel-debugger_bundled_gdb

Custom GDB Executable:

I don't have GCC/GDB installed on my system, so I don't have a "Custom GDB Executable" to select.

However, if I try to use /usr/bin/lldb as a Custom GDB Executable, I get an error: lldb: unrecognized option '-interpreter=mi2'. As you might expect, this happens for both CLion+CMake and CLion+Bazel. Here's the image:

cmake_vs_bazel-debugger_custom_gdb

My Testing Environment

  • macOS 10.14.2 (Mojave)
  • CLion v2018.2.7 (Though CLion v2018.3.0+ are more recent, they don't seem to
    be compatible with the latest versions of the plugin.)
  • Two versions of the plugin, https://github.com/bazelbuild/intellij:
    • v2018.12.03.0.2 (latest pre-built release, retrieved within CLion)
    • 0f45ef4 (built from source)
  • File System: APFS (Case-sensitive, Encrypted)
$ xcodebuild -version
Xcode 10.1
Build version 10B61
$ c++ --version
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ bazel version
WARNING: --batch mode is deprecated. Please instead explicitly shut down your Bazel server using the command "bazel shutdown".
INFO: Invocation ID: d1b8eba4-dc65-4103-9351-c84a51b0c384
Build label: 0.21.0
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Dec 19 12:57:09 2018 (1545224229)
Build timestamp: 1545224229
Build timestamp as int: 1545224229

Questions

  • Is it possible that my Clang/LLVM/LLDB toolchain just isn't yet supported by the plugin?
  • If that is the case, how can I work around this?
  • Do I need to instead use a GCC/GDB toolchain?
  • If so, how should I configure my Bazel workspace, a cc_binary target, and a cc_library target to use another toolchain?
  • Is this related to Debugging C++ on MacOS does not work bazel#6327? When I use CLI lldb on my hello_world project, I see the same kind of thing in that issue. Might switching to a GCC/GDB toolchain at least let me use CLI gdb on my Bazel cc_binary targets?
@dwtj
Copy link
Author

dwtj commented Jan 12, 2019

FYI: The above-described problem is still observed when the environment variable BAZEL_USE_CPP_ONLY_TOOLCHAIN is set, as suggested here: #109 (comment)

@dwtj dwtj changed the title CLion Fails to Debug cc_binary target CLion Fails to Debug cc_binary target on macOS Jan 12, 2019
@brownry1986
Copy link

I am encountering the same issue with the latest versions of CLion and the Bazel plugin:

CLion version: CLion 2018.3.4
Bazel Plugin version: v2019.01.28.0.2

@songemeng
Copy link

I have the same problem. Bazel run is successful, but Debug fails. When I use the gdb which version is 7.11.1, I get an exit code 126.

@songemeng
Copy link

I got a solution for my situation.

  1. find the path of your gdb, such as /home/username/.CLion2018.3/config/plugins/clwb/gdb/. You
  2. sudo chmod a+x gdbserver

@blairmatte
Copy link

Also encountering this issue, same symptoms.

CLion version: 2018.3.4
Bazel Plugin version: v2019.03.05.0.1
cc version: Apple LLVM version 10.0.0 (clang-1000.11.45.5)

The suggestion above to chmod a+x gdbserver did not help for me. Happy to help debug or test solutions!

@jin jin added the product: CLion CLion plugin label May 1, 2019
@codingrhythm
Copy link

I am having the same issue. Is there a workaround, or work in progress to solve this issue?

@chaoren
Copy link
Collaborator

chaoren commented May 28, 2019

The solution from #494 (comment) still works, you have to chmod the correct gdbserver.

$ chmod +x $HOME/.CLion2018.3/config/plugins/clwb/gdb/gdbserver

if you're using CLion 2018.3.

$ chmod +x $HOME/.CLion2019.1/config/plugins/clwb/gdb/gdbserver

if you're using CLion 2019.1.

@chaoren
Copy link
Collaborator

chaoren commented May 28, 2019

If you download the plugin zip directly from here, and unzip into your plugins directory, it should also work. For some reason when you install it via the IDE marketplace it doesn't preserve the permissions.

ghost pushed a commit that referenced this issue May 28, 2019
CLion removes the executable permission on the gdbserver script if the
plugin is installed through the marketplace.

Don't need to worry about the executable bit if we always run directly
under bash.

PiperOrigin-RevId: 250287356
@blairmatte
Copy link

@chaoren This issue is specifically for macOS. I think your solution applies only for Linux. On macOS the folders you are describing do not exist. The corresponding folder on macOS appears to be $HOME/Library/Application\ Support/CLion2018.3/clwb/gdb/gdbserver. When I add execution permissions to this file there is no change to the debugging error in CLion.

@chaoren
Copy link
Collaborator

chaoren commented May 28, 2019

Yes, sorry, I only saw the last few comments on the issue. On mac we shouldn't be using the script at all.

@ghost ghost closed this as completed in #843 May 28, 2019
@chaoren chaoren reopened this May 28, 2019
@steeve
Copy link

steeve commented Jun 4, 2019

@chaoren do you have an idea of what needs to be done ?

ghost pushed a commit that referenced this issue Jun 4, 2019
@chaoren
Copy link
Collaborator

chaoren commented Jun 4, 2019

I'm hoping this would fix the issue, but since I don't have access to a mac at the moment, could I ask one of you people to build and test that patch to see if it works first?

@steeve
Copy link

steeve commented Jun 4, 2019

I'll take a shot, thank you!

@steeve
Copy link

steeve commented Jun 4, 2019

@chaoren Happy to report that it's working!

Attaching the build from the PR for other to use until it's released.

clwb_bazel.zip

@chaoren
Copy link
Collaborator

chaoren commented Jun 4, 2019

Excellent. I will merge the patch shortly.

@steeve
Copy link

steeve commented Jun 4, 2019

That said, debugging itself doesn't work because of bazelbuild/bazel#6327

ghost pushed a commit that referenced this issue Jun 4, 2019
@ghost ghost closed this as completed in f900728 Jun 4, 2019
@dwtj
Copy link
Author

dwtj commented Jun 4, 2019

Why was this closed? As @steeve said, debugging in CLion on macOS still doesn't work.

@chaoren
Copy link
Collaborator

chaoren commented Jun 4, 2019

The issue with the bazel plugin has been fixed. The other issue is in bazel, you should follow that other bug. There's nothing actionable on this bug anymore.

krlvi pushed a commit to krlvi/intellij that referenced this issue Sep 20, 2019
aradchykov pushed a commit to aradchykov/intellij that referenced this issue Oct 6, 2019
@wesleyw72
Copy link

Would this be fixed if we launched debugserver using the run_under flag, much like how gdbserver is used on Linux? That would then be executed in the sandbox which should still have the debug symbols intact.

@mikepii
Copy link

mikepii commented Dec 1, 2019

I think there's still another issue with the plugin on macOS (separate from the red popup error which seems to have been fixed, and separate from bazel issue bazelbuild/bazel#6327).

There's a workaround discussed in bazelbuild/bazel#6327: adding --spawn_strategy=standalone. I added that to my CLion run configuration. Contrary to before, now the executable that gets generated when I click "Debug" in CLion works correctly in lldb itself (I can set and stop at breakpoints and see the source). Also, CLion will now stop and highlight the correct line if I cause an exception e.g. with return *(int*)0;. But CLion still won't stop at breakpoints.

I'm using plugin version 2019.11.14.0.1 and I also tried the patched version in #494 (comment) above (same behavior). CLion does seem to be using LLDB because the Debug tool window includes a functioning LLDB shell.

@wesleyw72
Copy link

Please can we reopen this issue? It is definitely still broken. @chaoren

@chaoren chaoren reopened this Dec 16, 2019
@cloggo
Copy link

cloggo commented Feb 27, 2020

Please can we reopen this issue? It is definitely still broken. @chaoren

At least for Mac it is is still broken.

@wesleyw72
Copy link

I have a workaround which may be useful for others.

  1. Ensure that sandboxing is disabled. This involves setting --spawn_strategy=local and rebuilding to ensure that the files necessary for debugging aren't hidden away in the sandbox.
  2. Setup an .lldbinit to have an entry such as settings set target.source-map . <path_to_repo>. This enables breakpoints to be resolved correctly.
  3. If using Runfiles, you may have to setup variables such as TEST_SRCDIR as they aren't setup due to lldb not being run under bazel.

@chnlior-click
Copy link

@wesleyw72 , thank you very much.
I can confirm that the settings set target.source-map . <path_to_repo> made the magic and CLion breakpoints are finally working.

Another tip is that .lldbinit can be done in a project level as explained here

@CaichaoGitHub
Copy link

CaichaoGitHub commented Sep 29, 2020

@dwtj could you debug on macos with clion ?

i built your project < example > successfully and i could run it directly , but i can't debug it
clion just stuck on debug state and disable my breakpoints,

my environment:
xcode : 12.0
clion: v2019.3.6
bazel plugin : v2020.07.13
bazel : release 3.5.0

image

@mai93 mai93 added lang: c++ C++ rules integration topic: debugging Issues related to debugging os: macos macOS support type: bug labels Feb 9, 2021
@sgowroji
Copy link
Member

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

@sgowroji sgowroji closed this as not planned Won't fix, can't repro, duplicate, stale Jan 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lang: c++ C++ rules integration os: macos macOS support product: CLion CLion plugin topic: debugging Issues related to debugging type: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.