ghost
commented
5 years ago I have also left a comment here in case it is an issue with vs-code go: https://github.com/microsoft/vscode-go/issues/2010#issuecomment-517326186
Closed ghost closed 4 years ago
ghost
commented
5 years ago I have also left a comment here in case it is an issue with vs-code go: https://github.com/microsoft/vscode-go/issues/2010#issuecomment-517326186
awood45
commented
5 years ago 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: https://github.com/aws/aws-toolkit-jetbrains/issues/649
jackmcguire1
commented
5 years ago perhaps try debugging commands specified in https://github.com/Microsoft/vscode-go/issues/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
{ "go.delveConfig": { "apiVersion":1 } }
for reference https://github.com/awslabs/aws-sam-cli/issues/886
ghost
commented
5 years ago 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
{ "go.delveConfig": { "apiVersion":1 } }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 vscode-go-debug.txt
jackmcguire1
commented
5 years ago Ok i have just debugged my API endpoint using VScode to debug with APi-Version 2, however, I have rectified the launch.json.
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?
{ "version": "0.2.0", "configurations": [ { "name": "Connect to Lambda container", "type": "go", "request": "attach", "mode": "remote", "remotePath": "", "port": 5986, "host": "127.0.0.1" }, ] }
ghost
commented
5 years ago I tried your launch.json but unfortunately I'm still getting
SetBreakPointsRequest
All cleared
Creating on: H:\Branches\Git\newAttempt\sam-app\hello-world\main.go:25
Creating on: H:\Branches\Git\newAttempt\sam-app\hello-world\main.go:26
Creating on: H:\Branches\Git\newAttempt\sam-app\hello-world\main.go:30
Error on CreateBreakpoint: could not find file H:\Branches\Git\newAttempt\sam-app\hello-world\main.go
Error on CreateBreakpoint: could not find file H:\Branches\Git\newAttempt\sam-app\hello-world\main.go
Error on CreateBreakpoint: could not find file H:\Branches\Git\newAttempt\sam-app\hello-world\main.go
All set:[null,null,null]this feels like a vscode issue in regards to file location, you're running the file from a separate drive by the looks of it... which could be an issue? could you copy your code on to your c:/ drive and also paste your template.yaml file
jackmcguire1
commented
5 years ago ghost
commented
5 years ago 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 sam init --runtime go1.x, but I'll attach it anyway added txt onto the ending to upload it to github.
[14:53:45.337 UTC] To client: {"seq":0,"type":"response","request_seq":2,"command":"launch","success":true}
[14:53:45.340 UTC] From client: setBreakpoints({"source":{"name":"main.go","path":"h:\\Branches\\Git\\newAttempt\\sam-app\\hello-world\\main.go"},"lines":[25],"breakpoints":[{"line":25}],"sourceModified":false})
[14:53:45.340 UTC] SetBreakPointsRequest
[14:53:45.340 UTC] All cleared
[14:53:45.341 UTC] Creating on: H:\Branches\Git\newAttempt\sam-app\hello-world\main.go:25
[14:53:45.345 UTC] Error on CreateBreakpoint: could not find file H:\Branches\Git\newAttempt\sam-app\hello-world\main.go
[14:53:45.345 UTC] All set:[null]
[14:53:45.347 UTC] To client: {"seq":0,"type":"response","request_seq":3,"command":"setBreakpoints","success":true,"body":{"breakpoints":[{"verified":false,"line":25}]}}
[14:53:45.347 UTC] SetBreakPointsResponse
[14:53:45.362 UTC] From client: setExceptionBreakpoints({"filters":[]})
[14:53:45.362 UTC] To client: {"seq":0,"type":"response","request_seq":4,"command":"setExceptionBreakpoints","success":true}
[14:53:45.366 UTC] From client: configurationDone(undefined)
[14:53:45.367 UTC] ConfigurationDoneRequest
[14:53:45.368 UTC] ContinueRequest
[14:53:45.368 UTC] To client: {"seq":0,"type":"response","request_seq":5,"command":"configurationDone","success":true}
[14:53:45.368 UTC] ContinueResponse
[14:53:45.374 UTC] From client: threads(undefined)
[14:53:45.375 UTC] To client: {"seq":0,"type":"response","request_seq":6,"command":"threads","success":true,"body":{"threads":[{"id":1,"name":"Dummy"}]}}Whoops sorry - I copied from the wrong vscode-debug.txt - here is the right one
[16:10:30.861 UTC] To client: {"seq":0,"type":"response","request_seq":2,"command":"attach","success":true}
[16:10:30.867 UTC] From client: setBreakpoints({"source":{"name":"main.go","path":"c:\\Users\\james.walker\\source\\repos\\newAttempt\\sam-app\\hello-world\\main.go"},"lines":[25,26,30],"breakpoints":[{"line":25},{"line":26},{"line":30}],"sourceModified":false})
[16:10:30.868 UTC] SetBreakPointsRequest
[16:10:30.868 UTC] All cleared
[16:10:30.868 UTC] Creating on: C:\Users\james.walker\source\repos\newAttempt\sam-app\hello-world\main.go:25
[16:10:30.869 UTC] Creating on: C:\Users\james.walker\source\repos\newAttempt\sam-app\hello-world\main.go:26
[16:10:30.869 UTC] Creating on: C:\Users\james.walker\source\repos\newAttempt\sam-app\hello-world\main.go:30
[16:10:30.872 UTC] Error on CreateBreakpoint: could not find file C:\Users\james.walker\source\repos\newAttempt\sam-app\hello-world\main.go
[16:10:30.873 UTC] Error on CreateBreakpoint: could not find file C:\Users\james.walker\source\repos\newAttempt\sam-app\hello-world\main.go
[16:10:30.873 UTC] Error on CreateBreakpoint: could not find file C:\Users\james.walker\source\repos\newAttempt\sam-app\hello-world\main.go
[16:10:30.873 UTC] All set:[null,null,null]
[16:10:30.873 UTC] To client: {"seq":0,"type":"response","request_seq":3,"command":"setBreakpoints","success":true,"body":{"breakpoints":[{"verified":false,"line":25},{"verified":false,"line":26},{"verified":false,"line":30}]}}
[16:10:30.874 UTC] SetBreakPointsResponse
[16:10:31.058 UTC] From client: setExceptionBreakpoints({"filters":[]})
[16:10:31.058 UTC] To client: {"seq":0,"type":"response","request_seq":4,"command":"setExceptionBreakpoints","success":true}
[16:10:31.093 UTC] From client: configurationDone(undefined)
[16:10:31.094 UTC] ConfigurationDoneRequest
[16:10:31.094 UTC] ContinueRequest
[16:10:31.094 UTC] To client: {"seq":0,"type":"response","request_seq":5,"command":"configurationDone","success":true}
[16:10:31.094 UTC] ContinueResponse
[16:10:31.103 UTC] From client: threads(undefined)
[16:10:31.103 UTC] To client: {"seq":0,"type":"response","request_seq":6,"command":"threads","success":true,"body":{"threads":[{"id":1,"name":"Dummy"}]}}Also I tried changing handler to main - but it just result in a command line error when invoking the lambda.
could not launch process: fork/exec /var/task/main: no such file or directory
jackmcguire1
commented
5 years ago 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.
KarthickEmis
commented
5 years ago @jackmcguire1 i tried the same in visual studio code for go lang .. I am getting the below error
{ "errorMessage": "fork/exec /tmp/lambci_debug_files/dlv: exec format error", "errorType": "PathError" }?[0m 2019-08-27 17:42:43 Function returned an invalid response (must include one of: body, headers, multiValueHeaders or statusCode in the response object).
Note:
I modifed Handler name to main in template.yaml
I created the project through sam init --runtime go1.x
Installed docker ...
in my docker images i have lambci/lambdaimage only.
Below command are used :
set GOARCH=amd64 set GOOS=linux mkdir debugger go build -gcflags "all=-N -l" -o ./debugger/dlv github.com/go-delve/delve/cmd/dlv go build -gcflags "all=-N -l" -o hello-world/hello-world ./hello-world sam local start-api -d 5987 --debugger-path ./debugger --debug-args="-delveAPI=2"
PFA my template.yaml file and launch.json file. template.txt
{ // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "Launch", "type": "go", "request": "attach", "mode": "remote", "remotePath": "", "port": 5988, "host": "127.0.0.1" // "program": "${fileDirname}", // "env": {}, // "args": [] } ] }
whether i need to run dlv in my container and need to point out in build command ? If so kindly give some example.
KarthickEmis
commented
5 years ago I just tried the below steps sam init --runtime go1.x cd sam-app code . # to launch VSCode go get -u github.com/go-delve/delve/cmd/dlv GOARCH=amd64 GOOS=linux go build -o ./dlv github.com/go-delve/delve/cmd/dlv go get -u github.com/aws/aws-lambda-go/... GOARCH=amd64 GOOS=linux go build -gcflags='-N -l' -o hello-world/hello-world ./hello-world sam local start-api -d 5986 --debugger-path . --debug-args="-delveAPI=2"
debugger is not attaching in VS code .. but code is running
KarthickEmis
commented
5 years ago @jackmcguire1 , could you specify the version of your GoLang , VS Code , CLI used?
jackmcguire1
commented
5 years ago 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 Response observe the hello world code and make sure it is returning api gateway response with the body being set @KarthickEmis
I was incorrect about having main in template, keep it to hello world!!!
jackmcguire1
commented
5 years ago I hope this helps ^^
KarthickEmis
commented
5 years ago 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 Response observe the hello world code and make sure it is returning api gateway response with the body being set @KarthickEmis I was incorrect about having main in template, keep it to hello world!!!
@jackmcquire1 , I tried with new simple go lang program
sam init --runtime go1.x cd sam-app code . # to launch VSCode go get -u github.com/go-delve/delve/cmd/dlv set GOARCH=amd64 set GOOS=linux go build -o ./dlv github.com/go-delve/delve/cmd/dlv go get -u github.com/aws/aws-lambda-go/... set GOARCH=amd64 set GOOS=linux go build -gcflags="-N -l" -o hello-world/main ./hello-world sam local start-api -d 5989 --debugger-path . --debug-args="-delveAPI=2"
debugger is not attaching in VS code .. but code is working( value is returning in browser)
When i try to run the below command , sam local start-api -d 5989 --debugger-path . --debug-args="-delveAPI=2" , i can see upto the below lines in terminal 2019-08-28 10:42:16 Mounting C:\go-work\src\sam-app1\sam-app\hello-world as /var/task:ro,delegated inside runtime container Could not create config directory: mkdir .config: read-only file system.API server listening at: [::]:5989 2019-08-28T05:12:17Z info layer=debugger launching process with args: [/var/task/main],
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 ?[32mSTART RequestId: 959e2982-4823-1ac4-38a2-db2fb097b6d0 Version: $LATEST?[0m ?[32mEND RequestId: 959e2982-4823-1ac4-38a2-db2fb097b6d0?[0m ?[32mREPORT RequestId: 959e2982-4823-1ac4-38a2-db2fb097b6d0 Duration: 1178.29 ms Billed Duration: 1200 ms Memory Size: 128 MB Max Memory Used: 30 MB ?[0m 2019-08-28 10:42:59 No Content-Type given. Defaulting to 'application/json'. 2019-08-28 10:42:59 127.0.0.1 - - [28/Aug/2019 10:42:59] "GET /hello HTTP/1.1" 200 - 2019-08-28 10:42:59 127.0.0.1 - - [28/Aug/2019 10:42:59] "GET /favicon.ico HTTP/1.1" 403
Note: I tried -delveAPI=1 also , but not working versions in my system : VsCode: 1.37.1 aws-cli - 1.16.26 aws sam cli 0.19.0 Docker For Windows: 19.03.1
My launch.json { // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "Connect to Lambda container", "type": "go", "request": "attach", "mode": "remote", "remotePath": "/var/task/main", "port": 5989, "host": "127.0.0.1" // "program": "${workspaceRoot}", // "env": {}, // "args": [] } ] }
Kindly let me know whether delve has to run in container , if so provide me the steps to run.
jackmcguire1
commented
5 years ago 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
KarthickEmis
commented
5 years ago 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 , I am using the latest version of vs code ( version 1.37.1). Kindly let me know your availability time , so that we can join through team viewer or skype
ghost
commented
4 years ago @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 - https://github.com/microsoft/vscode-go/issues/2010
However this might be more easily resolved on the AWS SAM end by mounting source code
ghost
commented
4 years ago @KarthickEmis @jackmcguire1 After further investigation into the Delve debugger , I've discovered the following:
sam local start-api -t api-gateway.yml -d 5987 --debugger-path ./api/bin --debug-args="-debug -delveAPI=2"{
"type": "go",
"name": "Connect to Lambda container",
"request": "attach",
"mode": "remote",
"remotePath": "/c/git/linux/exampleFile"
"port": 5987,
"host": "127.0.0.1",
"showLog": true,
"trace": "log"
}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: 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 running