Breakpoint on absolute path not working #1730
Start listening for debug clients:
So the issue is that
To reproduce, the kubernetes software in question was built by checking out the kubernetes trunk and running
btw my GOPATH folder is actually named GOPATH, it's not a shell expansion problem in case you wondered.
dlv version 1.3.2
My suggestion: Could you maybe add some more detailed logging to the error "Location not found"? Is the file not found? Surely it has to be found, it's right there, the path is absolute. So how can it not be found, there has to be something else going on here.
The text was updated successfully, but these errors were encountered:
Hm, I agree that the error message could be more descriptive here as to what actually went wrong when looking up the location.
However, is there any actual code at the location you're trying to set a breakpoint at? What if you use the absolute path and line 32 like the breakpoint above which succeeded?
yeah line 34 has some code on it. I didnt change anything in kubernetes, here: https://github.com/kubernetes/kubernetes/blob/2905275a08f8e3999e7e6bc8b02f407fd6a0ff36/cmd/kube-apiserver/apiserver.go#L34
The way your code is built might affect this (paths and all). Let me know if you tried from GoLand 2019.2.3 (since you mentioned the IDE), and if it fails. The IDE itself has some heuristics to figure out where to put the breakpoint and the path matching is automatic.
I am using Goland IDE EAP 2019.3 it fails the "same" (=I use the Go Remote configuration) as what I'm doing here on the command line, I only tried the command line stuff because Goland wasnt working and then I switched to VsCode and that was showing me the actual error that the breakpoint cant be set, which I didnt know from inside Goland. I put "same" into quotes because I have no idea what Goland is doing internally, I'm not seeing any output in the console window of Goland IDE.
Or did you mean whether the non-bazel build&debug process works in Goland? Yes it does but that isnt useful to me because it takes too long to rebuild constantly even when I changed nothing, whereas with Bazel I can reuse a build.
Also btw regarding Delve it's very hard to get out of the delve command line when it's listening after it got a connection... ctrl+c doesnt work, ctrl+d doesnt, ctrl+z doesnt. I always have to close the whole terminal window.
The problem is almost certainly that the file can not be found. I bet bazel just strips the absolute paths from the executable, you can verify it by giving delve the command
If the file had been found the error would be different and would tell you specifically about the line not containing a statement. In fact the error that you get from IDEs should also be different given what API they are using, and I bet it tells you that it couldn't find the file explicitly. The reason the command line client doesn't tell you about files is because
Delve doesn't look on disk, it looks through the debug symbols inside the executable file. I think what's happening is that bazel is stripping the path prefix.
Besides checking the output of the sources command you can also see this from the output of
if the file had an absolute path it would show you something that either starts with
The solution is that your IDE and your build system need to agree on how they are going to tell the debugger how to locate files.
Ok but I cant exactly change how these IDEs want to do their debugging and I dont see any option for bazel+go to change the debug symbol paths either, at least I havent found anything with google searches just now.
GoLand looks at whatever the paths are in the binary and based on the configuration of the project, it can infer the paths to match the debugged target when debugging.
By the sounds of it, something went wrong with the heuristics in this case.
I know there's a Bazel plugin, https://plugins.jetbrains.com/plugin/8609-bazel/, which might be able to help you in this case.
That would be substitute-path, but what you want is the opposite, you want something in delve that removes a prefix from locations requested by IDEs.
I think you are experiencing a failure in the I part of IDE.