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

已完成

I'm not really sure what other information to provide. I click a line like I would for usual debugging, then I start the debugger and no matter what I've tried I get this:

The error is fairly misleading as it is next to a statement. It's fine up until I actually hit the debug button and then it displays that cross. I have this enabled:

0

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?

0

@...

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.

0

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).

0

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?

0

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

0

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.

0

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.

2

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.

1

@... 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!

0

@... - 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)

0

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.

0

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 😂

 

0

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

0

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

0

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.

0

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

Here are some ways to prevent dead code elimination optimization in Golang:
 
1. Add //go:noinline comment before the function:
go
//go:noinline 
func unusedFunc() { ... }
This tells the compiler not to optimize away this function.
 
2. Use go build with -gcflags parameter:(best)
bash
go build -gcflags="-N -l" 
The -N flag disables certain optimizations, including dead code elimination.
The -l flag prevents the compiler from inlining function calls, which also helps retain unused functions.
 
3. Use a variable to "escape" the function to the heap or goroutines:
go
var dummy = unusedFunc  // unusedFunc is now used
This prevents unusedFunc from being optimized away because dummy escapes it.
 
4. Call the unused function in an "if debug" statement:
go
func unusedFunc() { ... }  

if debug {  
    unusedFunc()  // The function is called in debug mode
}
The compiler cannot determine if debug is true, so it does not optimize unusedFunc.
 
5. Use runtime.KeepAlive to keep the function alive:
go
runtime.KeepAlive(unusedFunc) 
This tells the compiler that unusedFunc is "alive" and should not be optimized.These are some ways to prevent dead code elimination optimization in Golang. The main idea is to make unused functions "useful" in some way so that the compiler does not optimize them away
0

请先登录再写评论。