Golang lambda can't hit breakpoints in VSCode #1310
Comments
|
I have also left a comment here in case it is an issue with vs-code go: microsoft/vscode-go#2010 (comment) |
awood45
added
area/debugging
platform/windows
priority/3-long-term
type/feature
|
This is something we want to support, but I don't think at this point we officially support breakpoint debugging in Go. It is promising to see that goland step-through debugging is working, so will keep this open for reference. Related: aws/aws-toolkit-jetbrains#649 |
|
perhaps try debugging commands specified in microsoft/vscode-go#1555 For now, i would recommend not running delveAPI=2 with your debug command as it will default back to version 1, which VS code can support by specifying this within settings.json for vs code for reference #886 |
Unfortunately I tried API version one, and still couldn't set the breakpoint, attached is my debug logs - seems it can't find the file when setting the breakpoint even though it exists on disk |
|
Ok i have just debugged my API endpoint using VScode to debug with APi-Version 2, Could it be your template / handler configuration? you have said it works within Goland, so I don't see this being the issue, perhaps the folder which visual studio code has opened?
|
|
I tried your launch.json but unfortunately I'm still getting |
|
this feels like a vscode issue in regards to file location, |
|
see microsoft/vscode-go#2318 aswell |
|
I've just copied it to C:\ and get the same error message below but for the C:\ drive - my template.yaml is just the one generated by |
|
Whoops sorry - I copied from the wrong vscode-debug.txt - here is the right one Also I tried changing handler to main - but it just result in a command line error when invoking the lambda. |
|
Yes apologies the template modification is wrong, this issue is definitely a windows / vscode issue I’m afraid, as it’s workjng fine for goland. |
|
@jackmcguire1 i tried the same in visual studio code for go lang .. I am getting the below error { Note:
set GOARCH=amd64 PFA my template.yaml file and launch.json file. { whether i need to run dlv in my container and need to point out in build command ? If so kindly give some example. |
|
I just tried the below steps debugger is not attaching in VS code .. but code is running |
|
@jackmcguire1 , could you specify the version of your GoLang , VS Code , CLI used? |
|
Your debug port in vs code settings in wrong!! It should be 5986 or whatever you set in ‘sam local start-api -d 5986’ Hi karth, according to your error, your hello world lambda is not returning a correct I was incorrect about having main in template, keep it to hello world!!! |
|
I hope this helps ^^ |
@jackmcquire1 , I tried with new simple go lang program sam init --runtime go1.x debugger is not attaching in VS code .. but code is working( value is returning in browser) When i try to run the below command , It get strucked after this .once I restart the debugger in VS code , I am getting value in browser and getting logs in terminal but not hitting break point. 2019-08-28T05:12:57Z debug layer=debugger continuing Note: My launch.json Kindly let me know whether delve has to run in container , if so provide me the steps to run. |
|
You can see in logs that debugger is continuing, so dlv is definitely running perhaps , not sure why vscode is not detecting / enforcing the break point, make sure go extension in vscode is upto date, etc. We could schedule to talk on discord or team viewer, I think you’re close to getting this working |
@jackmcguire1 , |
ghost
mentioned this issue
|
@jackmcguire1 I've been investigating this further including why VSCode does not debug and Goland down and it seems to be down to the fact that VSCode sends delve JSON-RPC commands specifying the location of the file and the line to breakpoint, and Goland sends the memory address to breakpoint at. For the former,when debugging remotely, Delve requires access to a copy of the source code so it knows where to set the breakpoint. However in AWS SAM, the Delve debugger, and the binary to be debuggged is run inside a temporary docker container, so Delve cannot locate the source file, fails to set the breakpoint, and the program completes. I tried to fix this by waiting until AWS SAM / delve halted for a debugger to attach, and then copying the source files into the docker instance via the AWS SAM file share, and using vscodes remotePath: to pick it up, but unfortunately Delve did not pick up the files. This might be solved by having AWS SAM mount the source code, and pointing Delve towards these files so vscode can work. I have also commented on issue the go extension for visual studio code - microsoft/vscode-go#2010 However this might be more easily resolved on the AWS SAM end by mounting source code |
|
@KarthickEmis @jackmcguire1 After further investigation into the Delve debugger , I've discovered the following:
Breakpoints fail when the compiled path is different then the composite path of remotePath, and the relative path to the file for the VSCode - it is not needed for source code on the remote machine, as this line info is built into the binary. Where my code was failing was because I built in WSL linux, but my vscode remote path did not have a linux style path to my code directory. Unfortunately, if I choose the option of compiling in Windows with GOOS=linux, then the paths compiled into the binary look like:
The nature of the slashes are different, and so the breakpoints are not hit. This would require either a change to Go build to change the compiled files on a window system with GOOS=linux, or more easily, to change VSCode so it send paths inP OSIX format when remote connecting to a linux machine. A third option is for delve to rewrite paths passed in so they are in POSIX format |
Description
When I attempt to debug a sample golang lambda via delve and vscode using
sam local start-api -d 5987 --debugger-path ./debugger --debug-args="-delveAPI=2" --debug, I cannot hit my breakpoints or pause the debugger, however delve does halt and wait for input;I can hit breakpoints in goland.
Steps to reproduce
Setup
Setup commands /batch script
My launch.json file in the same folder as the batch script is
Observed result
Expected result
Debugging to work with breakpoints.
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
sam --version: 0.18.0Add --debug flag to command you are runningThe text was updated successfully, but these errors were encountered: