Can't use breakpoint in main of a `cc_binary` when a `cpp_grpc_library` is linked to executable: "The breakpoint will not currently be hit. No executable code is associated with this line."

[Algomorph]

Description of the bug:

On a run configuration, I am unable to debug C++ code in a Bazel project. The breakpoints become marked as "unavailable", when I hover my cursor over them I get "The breakpoint will not currently be hit. No executable code is associated with this line."

The project is a mediapipe-based one, I hope that can help replicate the issue. No bazel or executable flags are used, they don't seem to affect the issue either way.

This seems very similar, if not the same as https://github.com/bazelbuild/intellij/issues/3499.

The workaround proposed didn't help (with restarting IDE, reloading project, etc.) Recreating the project (e.g. removing .clwb folder, re-creating the .bazelproject file and run configuration in question) didn't help.

Which category does this issue belong to?

No response

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

I've tried this in a barebone bazel project with a simple boilerplate "hello world" cc_binary, but the breakpoints worked as expected. At this point I am out of the time budget to try to zero in on this issue, at least for the time being.

Which Intellij IDE are you using? Please provide the specific version.

CLion 2024.1.1, Build #CL-241.15989.121, built on April 25, 2024

What programming languages and tools are you using? Please provide specific versions.

C++

What Bazel plugin version are you using?

2024.04.09.0.1-api-version-241

Have you found anything relevant by searching the web?

This issue seems very similar, if not the same as https://github.com/bazelbuild/intellij/issues/3499.

Any other information, logs, or outputs that you want to share?

Full IDE info:

CLion 2024.1.1
Build #CL-241.15989.121, built on April 25, 2024
Licensed to Presage Security, Inc / Gregory Kramida
Subscription is active until November 19, 2024.
Runtime version: 17.0.10+1-b1207.14 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 6.5.0-28-generic
GC: G1 Young Generation, G1 Old Generation
Memory: 8192M
Cores: 32
Registry:
  actionSystem.update.actions.warn.dataRules.on.edt=false
  debugger.attach.dialog.enabled=true
  run.processes.with.pty=TRUE
  ide.experimental.ui=true
  ide.slow.operations.assertion=false
Non-Bundled Plugins:
  idea.plugin.protoeditor (241.15989.49)
  org.turbanov.run.configuration.as.action (3.0)
  dev.meanmail.plugin.nginx-intellij-plugin (2022.1.1)
  A move tab left and right using the keyboard plugin - by momomo.com (12.550)
  co.bito.bito-intellij (1.3.2)
  com.mikejhill.intellij.movetab (2.1.1)
  ru.adelf.idea.dotenv (2024.1)
  kemoke.net.cssmodule (1.1)
  com.haulmont.rcb (241.14494.140)
  com.google.idea.bazel.clwb (2024.04.09.0.1-api-version-241)
Current Desktop: ubuntu:GNOME

Attached log is from opening IDE, launching the debugger (which is unable to hit a breakpoint on first line in main), stopping the debugger, and saving the logs. idea.log

[Algomorph]

As an aside, this appears to be a either regression or possibly caused by some change in Bazel version CL-241.15989.121 (April 25): the debugging used to work before April 25-26 in the same project.

[tpasternak]

Hello, thank you for reporting the issue. Could you please confirm the regression happened in the last release, or (even better) provide a minimal reproducible example?

[Algomorph]

@tpasternak , I really can't spare the time right now on trying to figure out what's different between the MP(MediaPipe)-based project and a barebone hello-world MRE I've tested to get you an MRE that works. What I can do -- if you indicate it's sensible -- is try on a specific open-source MP branch and one of the desktop examples there, would that help you? In terms of reverting back to a previous version -- do you mean of Clion or of Bazel Plugin or both? If you can provide any step-by-step guidance (or link to such) for reverting (on a Linux platform, if that is relevant), I can try this. Aside: I was trying yesterday on Mac with CLion 2023.2, but there the debugging never seemed to work from the beginning (debugging symbol greyed out). Tempted to try and upgrade that to see what gives.

[tpasternak]

oh, I understand, so:

1. To revert the plugin you can install it manually from the marketplace site https://plugins.jetbrains.com/plugin/9554-bazel-for-clion/versions
2. To revert CLion - please just try JetBrains Toolbox
3. When comes to debugging on Mac - recently we began to support some time ago https://github.com/bazelbuild/intellij/issues/2101

[Algomorph]

Reporting back. I've tried debugging using:

CLion: 2023.3.4, Build #CL-233.14475.31 (Feb 13, 2024)
Bazel for CLion: 2024.03.12.0.1-api-version-233 and 2024.04.09.0.1-api-version-233

No joy. Same symptoms in both cases, "No executable code is associated with this line".

This makes me think now that the refactor I applied recently caused debugging to fail. ~Essentially, what I did was removing mediapipe sources from my project's sources and importing mediapipe via a git_repostory rule into the project's WORKSPACE instead, but I don't see how this could make any difference.~

[Algomorph]

I was able to narrow down exactly the target which is causing the debugging symbols not to work. The rule used to produce the target is a cpp_grpc_library (reference documentation).

Here are the relevant code snippets:

cc_binary(
    name = "hello_world",
    srcs = [
        "main.cc",
    ],
    deps = [
        "//graph:physiology_service_cpp_grpc",
    ],
)

cpp_grpc_library(
    name = "physiology_service_cpp_grpc",
    protos = [":physiology_service_proto"],
)

proto_library(
    name = "physiology_service_proto",
    srcs = ["physiology_service.proto"],
    deps = [
        "@com_google_protobuf//:empty_proto",
        "@com_google_protobuf//:wrappers_proto",
    ],
)

It matters not whether any headers from the cpp_grpc_library are actually used. I did not, i.e. I used the boilerplate hello_world in main.cc:

#include <iostream>

int main() {
    std::cout << "Hello World!";
    return 0;
}

Here is the physiology_service.proto text used in example above, if that makes any difference. My intuition is telling me you can have almost anything in here.

syntax = "proto3";
import "google/protobuf/empty.proto";
import "google/protobuf/wrappers.proto";

package presage.physiology.preprocessing;

service Physiology {
  rpc GetMetricsFromBuffer(PreprocessedDataBuffer) returns (MetricsBuffer);
  rpc GetHeartRate(HrPreprocessedFrameData) returns (HeartRate);
  rpc GetRespiratoryRate(RrPreprocessedFrameData) returns (RespiratoryRate);
  rpc IssueBlueTooth(BlueTooth) returns (google.protobuf.Empty);
  rpc SetBufferDuration(google.protobuf.DoubleValue) returns (google.protobuf.Empty);
}

// region ==== input messages

message Point2dInt32 {
  int32 x = 1;
  int32 y = 2;
}

message Point2dFloat {
  float x = 1;
  float y = 2;
}

message Point3dFloat {
  float x = 1;
  float y = 2;
  float z = 3;
}

message HrPreprocessedFrameData {
  repeated Point2dInt32 face_landmark = 1;
  repeated Point3dFloat roi_bgr_average = 2;
  double time_now = 3;
}

message RrPreprocessedFrameData {
  repeated Point2dFloat tracked_point = 1;
  repeated int32 tracked_point_label = 2;
  bool reset = 3;
  double time_now = 4;
}

message PreprocessedDataBuffer {
  repeated HrPreprocessedFrameData hr_data = 1;
  repeated RrPreprocessedFrameData rr_data = 2;
}

message BlueTooth {
  double time_now = 1;
  double time_elapsed = 2;
}
// endregion ===
// region === output messages
message HeartRate {
  double value = 1;
  double time = 2;
}

message RespiratoryRate {
  double value = 1;
  double time = 2;
}

message MetricsBuffer {
  repeated HeartRate hr_data = 1;
  repeated RespiratoryRate rr_data = 2;
}
// endregion ===

[ujohnny]

5604 dup?

[Algomorph]

I confirm, the posted workaround works for me.