Open adibrastegarnia opened 5 years ago
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.
dlv version
)? Delve Debugger Version: 1.2.0 Build: $Id: 068e2451004e95d0b042e5257e34f0f08ce01466 $go version
)? go version go1.12.5 darwin/amd64