delve
delve copied to clipboard
set breakpoints while the program is running
- What version of Delve are you using (
dlv version)? Delve Debugger Version: 1.2.0 Build: $Id: 068e2451004e95d0b042e5257e34f0f08ce01466 $ - What version of Go are you using? (
go version)? go version go1.12.5 darwin/amd64 - What operating system and processor architecture are you using? Mac os
- What did you do? Suppose we have a program which is keep running (a server) and we would like to continue and then set breakpoints while it is running. That means we don't want to set breakpoints and then continue, however, we would like to continue first and then set breakpoints. When I connect using dlv connect and then continue then I cannot set breakpoints anymore. If I use CTRL +C to return back to cli it gives me the message to kill the target to kill this client.
- What did you expect to see? Connect and continue immediately and then set breakpoints while it’s running
Just to add some more context to why this is needed: we’re using dlv to debug a distributed system running inside Kubernetes. Of course, distributed systems frequently rely on timeouts for failure detection, and this makes pausing program execution a nonstarter. After connecting and while setting breakpoints, Kubernetes will attempt and fail to probe the pod and will eventually kill it along with the debugging session. Even when probes are disabled, connecting the debugger and pausing program execution can cause e.g. leader changes in systems that do leader election using timeouts for failure detection. Sure, once the breakpoints are hit failure detectors will still be tripped, but at least that will happen before the debugger could cause a state change in the cluster. The act of attaching the debugger should not be creating state changes in systems that depend on time before they can even be debugged.
AFAIK setting breakpoints on a running process is impossible, the effect would still be that of halting, setting a breakpoint and resuming execution. This could be done automatically, either client side or in service/debugger.go. Either way it poses some UI challenges for a CLI client.
AFAIK setting breakpoints on a running process is impossible, the effect would still be that of halting, setting a breakpoint and resuming execution.
That's correct. It would just be a faster implementation of what the user would do (e.g stop -> set bp -> continue).
I think that would be a fine solution. It’s halting for slow user input that can cause the types of issues I mentioned.
May be a execution of commands in file, passed as cli parameter ? If attached to running process, than stop -> execute commands -> continue. Also may be useful for save debugging session parameters.