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.

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

Function call does not seem to work when calling function with the same arguments after the code calls it #1590

Closed
dlsniper opened this issue Jun 26, 2019 · 4 comments

Comments

@dlsniper
Copy link
Contributor

dlsniper commented Jun 26, 2019

  1. What version of Delve are you using (dlv version)?
    79ad269

  2. What version of Go are you using? (go version)?
    Go 1.12.6 or go version devel +bc27b64dba

  3. What operating system and processor architecture are you using?
    Windows 10 / amd64

  4. What did you do?
    Use the code from this repository: https://github.com/dlsniper/debugging/tree/0cf1692cb8518c1ec982c72d71064ffba1d0ed1c and replace the main.go file contents with the following ones: https://play.golang.org/p/dJWkRJx1cqN

Then, run the debugger as usual against the main.go and run the following commands:

b main.go:43
b main.go:61
c

When the breakpoint hits, invoke the following function call call strconv.ParseInt("123", 10, 64)

  1. What did you expect to see?
    I would expect to see the result of the evaluation.

  2. What did you see instead?
    I got the following error message:

call not at safe point

However, change the commands above to the following sequence and then the function call will work (the debugger is stopped at line 35):

b main.go:35
b main.go:43
b main.go:61
c

From my understanding, this comes from the Go runtime itself, and this does not seem to be fixed in Go 1.13 either, but please confirm this is the case and I'll follow-up with the Go team in a separate ticket.
Thank you!

@aarzilli
Copy link
Member

It doesn't have anything to do with whether the function was already called or not: some lines of code (really: some instructions) are not safe points and functions can't be called there, because the garbage collector wouldn't be able to deal with the resulting stack frame. Nothing we can do about it.

@dlsniper
Copy link
Contributor Author

Is there a way to know where these safe points are? For clients, this could be useful as they could tell the users a more clear error or suggest a different place to execute the calls.

@aarzilli
Copy link
Member

Is there a way to know where these safe points are?

No, we could parse the bitmap used by the runtime but since there's ongoing work on safepoints it's a bad time to do it.

@aarzilli
Copy link
Member

Closing, not a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants