Closed seflerZ closed 5 years ago
Well, I managed to solve my problem by setting the dlv backend to lldb and made some changes to the launch.json
Command:
dlv --headless --backend lldb --listen 0.0.0.0:30010 attach 239910 --log
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": "Remote Debug",
"type": "go",
"request": "launch",
"mode": "remote",
"remotePath": "/home/sefler/mygo/src/istio.io/istio/pilot",
"program": "${workspaceFolder}",
"apiVersion": 1,
"host": "172.16.9.245",
"port": 30010,
"trace": "verbose",
"env": {},
"args": []
}
]
}
In the launch.json file,
program
needs to point to the package or the entrypoint file in the local machine that is being debugged.remotePath
should point to the entrypoint file in the remote machine that is being debugged.So the changes you made are in line with the above.
About lldb, I am not sure why that would make a difference... Maybe because you are using api version 1?
I would be interested to know if things work when you use api version 2, keep the changes in the launch.json and not provide the --backend
argument for dlv
Thanks for replying. I've tried many times without "--backend", unfortunately resulted in the some. My dlv version is:
Delve Debugger
Version: 1.1.0
Build: $Id: 1990ba12450cab9425a2ae62e6ab988725023d5c $
I'm running VS Code on Windows 10 Pro and the target platform is Ubuntu 16.04 LTS. The target program is pilot-discovery component of Istio. Both side of dlv installed the same version.
@derekparker, @aarzilli This is a case of running the dlv headless on an ubuntu machine and attaching to it on a Windows machine using VS Code. Any idea why the --backend should be set to lldb here?
I'd like to see the output of dlv --headless --listen 0.0.0.0:30010 attach 239910 --log --log-output=rpc 2>send-me-this-file.thank-you
after connecting to it with VSCode.
Sorry keep you waiting. Here is all I've got. @aarzilli
The log tells there is no file in: /home/sefler/mygo/src/istio.io/istio/mixer/pkg/api/grpcServer.go:133
But when backing with lldb, as the picture shows, the file can be found.
I don't see a CreateBreakpoint request in the log you posted at all. All I see is VSCode requesting a list of all goroutines and then (probably) shutting down the receive end of the socket. This is the exchange truncated to 160 columns per line:
time="2018-12-17T12:59:47+08:00" level=debug msg="(async 2) <- RPCServer.Command(*api.DebuggerCommand{\"name\":\"continue\",\"ReturnInfoLoadConfig\":null})" lay
time="2018-12-17T13:00:02+08:00" level=debug msg="(async 3) <- RPCServer.Command(*api.DebuggerCommand{\"name\":\"halt\",\"ReturnInfoLoadConfig\":null})" layer=r
time="2018-12-17T13:00:02+08:00" level=debug msg="(async 2) -> *api.DebuggerState{\"Running\":false,\"currentThread\":{\"id\":58062,\"pc\":4565539,\"file\":\"/u
time="2018-12-17T13:00:02+08:00" level=debug msg="(async 3) -> *api.DebuggerState{\"Running\":false,\"currentThread\":{\"id\":58062,\"pc\":4565539,\"file\":\"/u
time="2018-12-17T13:00:02+08:00" level=debug msg="<- RPCServer.ListGoroutines(<nil>null)" layer=rpc
time="2018-12-17T13:00:05+08:00" level=debug msg="-> *[]*api.Goroutine[{\"id\":1,\"currentLoc\":{\"pc\":4376938,\"file\":\"/usr/local/go/src/runtime/proc.go\",\
time="2018-12-17T13:00:05+08:00" level=error msg="writing response:write tcp 172.30.60.210:30020->172.30.60.1:56185: write: broken pipe" layer=rpc
time="2018-12-17T13:00:05+08:00" level=debug msg="<- RPCServer.Restart(<nil>null)" layer=rpc
time="2018-12-17T13:00:05+08:00" level=debug msg="-> *int0 error: \"cannot restart process Delve did not create\"" layer=rpc
time="2018-12-17T13:00:05+08:00" level=error msg="writing response:write tcp 172.30.60.210:30020->172.30.60.1:56185: write: broken pipe" layer=rpc
so far this looks like a problem on VSCode's side.
Never mind, I see that you posted the wrong long and edited the message. It's very strange that you are getting that message on the native backend but not on with the lldb backend. That error shouldn't really depend on the backend at all. Even stranger is that you say that it works with gdlv. I'm not sure what to make of this. Maybe also post the same log but with --backend lldb
?
@seflerZ Do you still have this issue? If so, can you provide the logs like @aarzilli asked for in the previous comment?
I'm terribly sorry that the whole development environment has been lost. I'm using Hyper-V to experience the Istio, but last day the machine state went wrong(it was stuck at initiation phase) and could not work anymore. I've tried to make recovery but in vain.
Thank you for being active for this issue. Because I can not provide any further information at present, I think you can mark this issued as closed. If encountered the same problem again, I will mark it again.
Thanks, again!
Thanks @seflerZ
If you have a question, please ask it on https://gitter.im/Microsoft/vscode-go or on the VSCode channel in Gophers Slack(https://invite.slack.golangbridge.org/)
If you have issues around GOPATH, read https://github.com/Microsoft/vscode-go/wiki/GOPATH-in-the-VS-Code-Go-extension first.
If you have issues debugging your Go programs
"trace": "verbose"
and share the resulting logs in the debug consoleIf this is a bug report, please share
Steps to Reproduce:
Remote run "dlv --headless --listen 0.0.0.0:30010 attach 239910 --log" which 239910 is the target process id
Local VS Code launch.json:
Press "Start Debugging" button and the VS Code says connected, but nothing shows in the "DEBUG CONSOLE"
Create any break points result in no response at all
Unable to add break points after waiting. The verbose logs are: 9:44:30 PM, 12/3/2018 InitializeRequest InitializeResponse Using GOPATH: C:\Users\Sefler Zhou\go InitializeEvent ConfigurationDoneRequest ContinueRequest ContinueResponse SetBreakPointsRequest All cleared Creating on: C:\Users\Sefler Zhou\go\src\istio.io\istio\pilot\pkg\config\kube\crd\controller.go (C:/Users/Sefler Zhou/go/src/istio.io/istio/pilot/pkg/config/kube/crd/controller.go) :221
By using "gdlv" it works fine so my remote dlv API server should probably be well configured.