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

x/tools/gopls/internal/telemetry/cmd/stacks: automate stack context #64654

Open
findleyr opened this issue Dec 11, 2023 · 1 comment
Open

x/tools/gopls/internal/telemetry/cmd/stacks: automate stack context #64654

findleyr opened this issue Dec 11, 2023 · 1 comment
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@findleyr
Copy link
Contributor

Reminder issue: we should automate the context added to issues created by the stacks command (https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3Agopls%2Ftelemetry-wins).

In order to do this, we need a func(symbol, tag string) (linenumber int) in order to build the source location. Our benchmarks have some helpers to shallow clone, which we could extract and reuse.

Since we may need to adjust the relevant source location, we should make this functionality available as a subcommand (in addition to guessing it in the initial issue template). E.g. stacks context golang.org/x/tools/gopls/internal/server.diagnose 23.

CC @adonovan

@findleyr findleyr added this to the gopls/v0.16.0 milestone Dec 11, 2023
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Dec 11, 2023
@findleyr findleyr modified the milestones: gopls/v0.16.0, gopls/v0.17.0 Mar 13, 2024
@adonovan
Copy link
Member

adonovan commented Mar 25, 2024

Shallow cloning is the easy part. Parsing the stack frame out of the symbol name is the tricky bit. Consider this line from #66490:

golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.ServerHandler.func3:+5

If I understand correctly, this refers to a call 5 lines into an anonymous function defined within protocol.ServerHandler, which is inlined into (*streamServer).ServeStream, and because of the inlining becomes the third anonymous function within the combined function. The actual package name (protocol) isn't even mentioned! So not only do you have to parse the symbol name quite carefully, it then needs resolving relative to type information.

Inlining should be a compiler implementation detail. Instead of printing the runtime's inline-mangled symbol name, we should resolve it to a logical (file name, relative line, function name) triple upfront in x/telemetry's crashmonitor (#66517). This will break all our existing counter names, but will allow us to automate more of the triage burden.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

3 participants