Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

default name of output binary causes confusing behavior when delve is run twice from the same directory #3345

Closed
valscale opened this issue Apr 27, 2023 · 2 comments · Fixed by #3366
Closed

default name of output binary causes confusing behavior when delve is run twice from the same directory #3345

valscale opened this issue Apr 27, 2023 · 2 comments · Fixed by #3366
Labels
area/cli kind/bug

Comments

@valscale
Copy link

Up front: we are using a slightly forked version of Go; feel free to close as WONTFIX but it seems like something that would likely be present with mainline go.

I am running "dlv debug" simultaneously on two processes, one named "tailscale" and one named "tailscaled". Twice today I have restarted dlv, hit "c" to run, and gotten an error message from the binary I am debugging in my OTHER dlv session.

AFAICT, this happens when I kill and restart dlv while the other dlv session is running.

Specific steps:

  1. The "tailscaled" process is running in the first dlv.

  2. The "tailscale" process in the second dlv has run and exited.

  3. I quit the first dlv with "tailscaled" and restart it with exactly the same arguments and source. I type "c" to run it and it is running, waiting for API calls.

  4. In the second dlv, I type "r" to restart the "tailscale" process. I then type "c" to run it.

  5. At this point, I get an error message saying I've passed invalid command line arguments. It's the error message from the code I am debugging in the OTHER dlv session.

  6. If I then quit the first dlv session, restart it with the exact same arguments and source, and type "c", I get an error message from the code I am debugging in the second dlv session.

  7. What version of Delve are you using (dlv version)? 1.20.1

  8. What version of Go are you using? (go version)? go1.20.3-tsddff070 (1.20.3 with some tailscale specific patches)

  9. What operating system and processor architecture are you using? MacOS 13.3.1, arm64

  10. What did you do? Quit and restarted dlv while running another dlv session simultaneously, then ran the program.

  11. What did you expect to see? The output from the source code I specified on the command line.

  12. What did you see instead? The output from the source code I specified in the OTHER dlv session currently running.
@aarzilli
Copy link
Member

If you can reproduce this (semi)reliably you could reproduce it with --log --log-output=gdbwire so we could see what is happening.

@valscale
Copy link
Author

Thanks so much! I can definitely reproduce this 100% of the time now and finally got some time to run it with the flags you suggested.

NOTE: the commands are named tailscale and tailscaled (note the d). This may be related to the problem.

Attached are two files. The first one shows the output of dlv tailscaled with those flags, the second is dlv tailscale with those flags. Here is the sequence of actions:

  • Start dlv tailscaled, run the program (it is a server so it stays running)
  • Start dlv tailscale, set a break point in it, run the program, hit the break point
  • While dlv tailscale is paused in the break point, ctrl-c the dlv tailscaled, restart it ("r"), run it ("c"), and it prints out the error message from tailscale, showing that it attached to a different binary than it was started with

dlv tailscaled switches to tailscale.txt
dlv tailscale paused at breakpoint.txt

@aarzilli aarzilli changed the title simultaneous dlv sessions sometimes attach to the other session's process default name of output binary causes confusing behavior when delve is run twice from the same directory May 12, 2023
@aarzilli aarzilli mentioned this issue May 12, 2023
Merged
aarzilli added a commit to aarzilli/delve that referenced this issue May 12, 2023
@aarzilli
cmd/dlv,service/dap: use randomized name as default output binary
03e4a0e 
Using a fixed path as the default output binary means that executing
Delve twice in the same directory will cause the second invocation to
overwrite the output binary of the first instance of Delve, making the
restart command not work correctly.

Fixes go-delve#3345
aarzilli added a commit to aarzilli/delve that referenced this issue May 16, 2023
@aarzilli
cmd/dlv,service/dap: use randomized name as default output binary
b899f8d 
Using a fixed path as the default output binary means that executing
Delve twice in the same directory will cause the second invocation to
overwrite the output binary of the first instance of Delve, making the
restart command not work correctly.

Fixes go-delve#3345
derekparker pushed a commit that referenced this issue May 16, 2023
@aarzilli
cmd/dlv,service/dap: use randomized name as default output binary (#3366
84b757a 
)

Using a fixed path as the default output binary means that executing
Delve twice in the same directory will cause the second invocation to
overwrite the output binary of the first instance of Delve, making the
restart command not work correctly.

Fixes #3345
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/cli kind/bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

cmd/dlv,service/dap: use randomized name as default output binary aarzilli/delve
2 participants
@aarzilli @valscale