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

runtime: Stack() always returns 0 on windows/amd64 compiled with 6g v1.2.1 #7630

Closed
gopherbot opened this issue Mar 25, 2014 · 4 comments
Closed
Milestone

Comments

@gopherbot
Copy link
Contributor

by james.jdunne:

What does 'go version' print?
go version go1.2.1 windows/amd64

What steps reproduce the problem?
http://play.golang.org/p/Go2KPCaIDZ

What happened?
No stack trace returned from runtime.Stack() call. The function returns 0, indicating 0
bytes written to the pre-allocated buffer.

What should have happened instead?
I should get a stack trace for the current goroutine. runtime/debug.Stack() returns a
stack trace, but runtime.Stack() does not.

Please provide any additional information below.
@ianlancetaylor
Copy link
Member

Comment 1:

Labels changed: added repo-main, release-go1.3.

@minux
Copy link
Member

minux commented Mar 30, 2014

Comment 2:

line 19:
bytes := make([]byte, 0, 1048576)
is wrong. the slice provided to Stack has length of 0, so the only number Stack
could return 0.

Status changed to WorkingAsIntended.

@gopherbot
Copy link
Contributor Author

Comment 3 by james.jdunne:

That's C semantics, not  Go semantics. You have an allocated buffer with plenty
capacity. Length should be zero. The Stack function should fill the buffer up to
capacity at most, not its length. This would remove the need for the nonstandard int
return value representing the new length of the buffer.

@minux
Copy link
Member

minux commented Mar 30, 2014

Comment 4:

It is Go semantics. see also io.Reader.
API should generally not change len of a slice passed in (for example,
consider that, before the introduction of three index slides, what if
you have a custom []byte allocator that allocates from a big []byte?
Writing past the length might corrupt the memory of others unrelated
byte slices).

@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@rsc rsc removed the release-go1.3 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants