-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Remove first four calls of stacktrace #308
Comments
Remove `runtime.goexit`, `runtime.main`, and some zap frames from our stacktraces. Since we're now formatting our own traces, we also get a *big* performance win: nearly 5x faster and half the number of bytes allocated! Current master: ``` BenchmarkStackField-4 200000 9587 ns/op 960 B/op 2 allocs/op ``` After this PR: ``` BenchmarkStackField-4 500000 2149 ns/op 448 B/op 2 allocs/op ``` Fixes #308.
@akshayjshah I'm not sure if this is a regression or the intended behavior, but I'm still seeing a large number of frames being returned. Heres an example call to
My assumption is that those zap specific lines are supposed filtered out. Is that your assumption too, @peter-edge ? Taking a quick peek at the zap code, I see in stacktrace.go the array called _stacktraceIgnorePrefixes which holds the list of prefixes that get filtered. My current quick fix is just to add I took a look at #311 and the test cases but I can't tell what the intended behavior exactly is. |
Any update on this one? My logs are also full of stack frames from within |
The original issue was to filter out runtime stacks, and the very last zap stacktraces. I've filed a separate issue #488 to discuss whether all zap stack frames should be removed. |
When you get a stacktrace, it will always return:
This doesn't have much use to the user, so we should try to remove these. This might be a little tricky, I'll look into it at some point.
The text was updated successfully, but these errors were encountered: