GoLand with remote dlv gives  'could not find statement at <FULL_FILE_PATH>, please use a line with a statement'

Please, upload IDE logs with additional logging to http://uploads.jetbrains.com/ and provide its name:

1. Add #com.goide.dlv.DlvVm in Help | Diagnostic Tools | Debug Log Settings...
2. Restart the IDE
3. Reproduce the problem
4. Provide IDE logs via Help | Collect Logs and Diagnostic Data

Did you follow all steps from the documentation?

Daniil

Upload id: 2021_03_15_HPh3kReuXsW8JMH9 (file: goland-logs-20210315-142444.zip)

This is exactly how I'm setting up the debugger. The only change I made was to add `-gcflags="all=-N -l"` to the build in accordance with the docs. Same result though.

The strangest part is I had this working last week. I'm not sure what has changed. I even tried reverting to a commit from last week to see if it was a code change. No joy.

Could you please provide a screenshot of your Go Remote configuration (Run | Edit Configurations)? You will need to specify the host and port where the debugger is listening (the next line after dlv exec ... command).

I follow all steps in your docs without any issues, but I need to change your main.go file to debug configuration properly first. Could you please try to re-build your application and try to connect the debugger again? What the output from Delve after you run Go Remote configuration?

I did that - I was actually the person that added that bit of code and t hose instructions to the repo 😁

I also tried blowing away the project and redoing it in a new folder in case it was something wonky in the GoLand project settings.

Like I said, it was working. It's one of those things you go to bed one day, come back the next and it wasn't working. It's not magic so I know it is likely something I've done but I have no idea how to troubleshoot what that thing is that I've done hahaha

Update - so it's only certain files it seems. For example I *can* place breakpoints in `main.go` but not in the file I'm working on - resource_redfish_power.go. I have previously debugged this file successfully though so I'm still not sure what changed.

Got it working.

For anyone else who encounters this:

In my specific case (Terraform):

In my case I was debugging a Terraform provider. I had somehow removed my new resource from the ResourcesMap in the Provider. This results in some unexpected behavior, though sensible once you understand it. If the function with all the contexts is unused Go optimizes all that code out of the resulting binary. This is why you see the error that the line must have a statement - because in the compiled binary it doesn't exist. This is non-obvious because it won't be the function you're working on that necessarily isn't in use. I had to go look at the top level function to catch that this had happened. 

In the general case:

If you search around online you'll see a bunch of stuff related to pathing. That indeed could be your problem but also check to make sure that in some roundabout way your code isn't being optimized out of the resulting binary. This will lead to the aforementioned error message.

Thanks for the update. I think we can slightly improve the process from our side, e.g., provide a little bit informative message when a breakpoint isn't working properly due to binary optimization.

Daniil thanks a lot for working this with me. Having someone else sanity check me was really helpful in driving me in the right direction. Knowing at least one other person had it working made me step back and look for other, less obviously related, problems.

Thanks again!

Daniil - there might be a bug here. Now the breakpoints are working still but I get the cross (you can see the blue outline of the hit breakpoint in the background)

It seems like a bug. What were the previous steps? Did you compile the binary after making changes to the file? I'll try to reproduce the issue locally.

So what's really weird is I haven't changed much. After I wrote that post saying I had succeeded, I added a single line:

d.SetId(system.SerialNumber + "_power")

and then recompiled. After that it did it again. If it's easier for you guys, you can hit me up at grant_curell (at) dell (dot) com. I don't mind just giving you a Zoom session to my box. The stuff I'm working on right now is all open source. I know what it's like to try to troubleshoot a customer's problem via forum 😂

Thanks, I'll try to reproduce it on my side first. I've not seen that error before. Thanks for the details.

Sounds good! Let me know if there's anything I can do for you!

Thanks for pointing that. I filled out the new ticket: GO-10755. Feel free to follow. Please see if you're not familiar with YouTrack: Watching YouTrack issues.

I have found several ways to prevent this optimization so that we can do debugging. ps:I think the second one is the best.

go
//go:noinline 
func unusedFunc() { ... }

bash
go build -gcflags="-N -l" 

go
var dummy = unusedFunc  // unusedFunc is now used

go
func unusedFunc() { ... }  

if debug {  
    unusedFunc()  // The function is called in debug mode
}

go
runtime.KeepAlive(unusedFunc)