C++ project is not debuggable on CLion with bazel and grpc

[ctrysbita]

Description of the bug:

Cannot set breakpoint for C++ project that depends on bazel and grpc. The program doesn't stop on breakpoint.

GDB shows that the source file is not found:

GNU gdb (GDB; JetBrains IDE bundle; build 180) 13.1
Copyright (C) 2023 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-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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".
No source file named /home/xxx/undebuggable/example/main.cpp.

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

Just use this repo: https://github.com/ctrysbita/undebuggable

On Ubuntu 23.10, CLion is installed from snap store.

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

CLion #CL-232.9921.42

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

C++

What Bazel plugin version are you using?

2023.10.10.0.1-api-version-232

Have you found anything relevant by searching the web?

No response

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

No response

[rakshitasingh05]

https://screenshot.googleplex.com/47gBxPA2vMDJkQZ

I tried to reproduce the issue but it seems play button is showing as "nothing here". Could you please help us to reproduce the issue with the exact steps? I tried "https://github.com/bazelbuild/intellij/tree/master/examples/cpp" sample project last week and debugging is working as expected.

[ctrysbita]

2023-11-08.webm

@rakshitasingh05 Sorry I cannot login the google's internal system. You can easily reproduce the issue using the repo above and here is the screen recording.

[ujohnny]

https://screenshot.googleplex.com/47gBxPA2vMDJkQZ

I tried to reproduce the issue but it seems play button is showing as "nothing here".

"Nothing here" is a https://youtrack.jetbrains.com/issue/CPP-35949/C-C-scratches-are-not-runnable-in-bazel-project

[ujohnny]

I was able to reproduce it and have to say this is one of the strangest bugs I've ever seen. Indeed introduction of stack variable breaks debugging, and it breaks it even in gdb. Also if variable is changed to ServerBuilder *builder then the issue does not reproduce.

[ evgenii@fedora:dev/undebuggable ] > % gdb /home/evgenii/.cache/bazel/_bazel_evgenii/f68897120bad126ffa56aaf72af3a652/execroot/undebuggable/bazel-out/k8-dbg/bin/example/main  
...

(gdb) bt
#0  __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7fffffffdb30, rem=0x7fffffffdb30) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:71
#1  0x00007ffff7afceb7 in __GI___nanosleep (req=<optimized out>, rem=<optimized out>) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2  0x000000000041e650 in void std::this_thread::sleep_for<long, std::ratio<1l, 1000l> >(std::chrono::duration<long, std::ratio<1l, 1000l> > const&) ()
#3  0x000000000041e4de in main ()

we can also observe the following warning

(gdb) b main.cpp:9
No source file named main.cpp

This happens because there's no information of main.cpp as a source in debug information which can be checked with info sources.

Eventually I localized the issue to 2 build flags that plugin passes to debug build -- --dynamic_mode=off --fission=yes. I suspect that it's the second one as it makes debug symbols split and I believe gdb have issues loading all the symbols. I'll try to follow-up later and see if the fission can be optionally turned off.

related: gsplit-dwarf

[nd]

According to the gdb issue, it is a gcc bug. Clang might work better.

[kaliaumem]

My team has been having this exact issue for months, but we never managed to create a small repro case, so thanks a lot @ctrysbita :pray:

Based on your investigation, I just tried debugging an executable where the symbols could not be found, but this time adding --fission=no to the Bazel flags in the run configuration. I can confirm I'm able to set and hit breakpoints again, and see the values of variables!

It seems the user flags get added after the ones the plug-in injects, so it's a viable workaround for now.

[Algomorph]

@nd could you comment on the relationship between the -gsplit-dwarf in GCC and the --fission flag in bazel, so I can understand how the gcc issue you mentioned relates to this issue?

[Algomorph]

(never mind) per ChatGPT 4o:

When Bazel's --fission flag is used, it typically translates to the underlying compiler (such as GCC) being invoked with the -gsplit-dwarf flag