-
Notifications
You must be signed in to change notification settings - Fork 153
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
stack: Parse all functions #111
Conversation
Codecov Report
@@ Coverage Diff @@
## master #111 +/- ##
==========================================
+ Coverage 98.18% 98.50% +0.31%
==========================================
Files 6 6
Lines 276 334 +58
==========================================
+ Hits 271 329 +58
Misses 4 4
Partials 1 1
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
One thing that I'd really like input on is this: I'm torn on this. CC @prashantv |
internal/stack/stacks_test.go
Outdated
want: "example.com/foo/bar.baz", | ||
}, | ||
{ | ||
name: "created by/in goroutine", // Go 1.21 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we add some testdata of real stack traces from go 1.20 / 1.21 and ensure they parse correctly too?
Update:
|
Adds support to the stack parser for reading the full list of functions for a stack trace. This includes the function that created the stack trace; it's the bottom of the stack. We don't maintain the order of the functions since that's not something we need at this time. The functions are all placed in a set.
In Go 1.20, the "created by" lines do not include the "in goroutine" portion.
`Full()` was accidentally dropping the file names from the full traces.
The function tha created a goroutine should not be considered part of its stack. However, we can use that entry to mark the end of a stack trace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, can also do testdata traces in a follow-up, doesn't have to be part of this PR.
To verify the stacktrace parsing logic, generate real stack traces under the following conditions: - Go 1.21 - Go 1.20 installed with gimme - Go 1.21 with tracebackancestors=10 set The test verifies that the parsed stack traces do not include functions that we did not expect to see in a goroutine's trace.
Instead of matching for built-in functions with strings.Contains, use the parsed stack information to match function names exactly. Following this change, the only remaining strings.Contains are to match on the goroutine state: ``` % rg strings.Contains utils_test.go 84: if strings.Contains(s.State(), "run") { internal/stack/stacks_test.go 249: if strings.Contains(s.State(), "run") { ``` Resolves #41 Depends on #111
Adds support to the stack parser for reading the full list of functions
for a stack trace.
NOTE:
This includes the function that created the stack trace;
it's the bottom of the stack.
We don't maintain the order of the functions
since that's not something we need at this time.
The functions are all placed in a set.
This unblocks #41 (PR incoming)
and allows implementing an IgnoreAnyFunction option
(similar to #80 that has since stalled).
Depends on #110