3

I'm currently developing a plugin for a product. This product invokes this plugin, written in GO, which runs for a very short time.

Because it runs so quickly, it makes it very hard (almost impossible with my knowledge) to attach delve client to it.

Is there a way we can instruct the plugin binary to stop execution and wait for delve client to connect?

P.S. Right now I'm inserting fmt.Scanln() in main() as a workaround. It's not a big issue to continue using this approach if there are no alternatives.

Matej
  • 7,728
  • 4
  • 23
  • 30
  • Isn't that a default behaviour of dlv? There is a option `--continue` which will instrument it not to wait for client https://github.com/go-delve/delve/blob/master/Documentation/usage/dlv_debug.md#options otherwise it should wait – mbradac Oct 31 '22 at 23:40
  • 1
    Hi @mbradac, thanks for the reply. The issue is connecting to a child process which is not instantiated by delve but rather by the parent process. Since the child's process binary is built with the debug flags it is possible to attach delve to the process, however the process is short lived and it finishes before it's even possible to attach to it. I'm curious what would be the best approach to pause the child process before attaching delve to it, or how to attach delve automatically (without changing the codebase)? – Matej Nov 02 '22 at 10:01
  • Can I imagine your use case as https://gobyexample.com/spawning-processes eg executing command? If so, would something like `exec.Command("/path/to/dlv", "debug", "/path/to/built/projetct")` be an acceptable solution, for testing purposes only. Disclaimer: untested – mbradac Nov 02 '22 at 21:49
  • That's the thing, no changes to the code just to support debugging of a spawned process are desired. But thanks for the suggestion, appreciate it! – Matej Nov 03 '22 at 08:16

0 Answers0