It seems to me that this can be done easily enough by post processing the runtime.Stack output, and doing that would be preferable to making the implementation more complicated. I don't see why this needs to be in the standard library.

There's no guarantee in the documentation for runtime.Stack() that the format will remain stable, so post-processing it may be unreliable (in fact, the format has already changed at least once). The implementation wouldn't gain much complexity, since it appears to already have a flags parameter internally and this would just involve not outputting a couple of things.

Personally, I don't think it's worth the cost.

In any case we clearly cannot change runtime.Stack, as that would break the Go 1 compatibility guarantee (https://golang.org/doc/go1compat). Do you want to propose a new API, either in the runtime or the runtime/debug package? Then we can turn this into a proposal (see https://golang.org/s/proposal).

Indeed, it would have to be a new function. I think it'd have to be in the runtime package, since the Stack() function in runtime/debug just calls runtime.Stack(). Having looked more closely at runtime.Stack(), it appears to already have a couple of options:

• all - a parameter that controls whether to output a stacktrace for every goroutine.
• tracebackancestors - an option set via the GODEBUG environment variable.

It might be cleanest to have both of these, along with a new option to control inclusion of the goroutine header and function argument addresses, passed into this new function in either a StackOpts struct or a flags int parameter.

I would not be optimistic about approving a function that is complex enough to require a StackOpts struct. We're talking about an unusual use case that will benefit few people. The cost in additional complexity has to be very very low.

https://github.com/maruel/panicparse "deduplicates redundant goroutine stacks" among some other useful utilities -- its source might be a good starting point for a third-party utility for deduplicating stack traces from separate crashes.

I think this is waiting on a concrete proposal (per #29769 (comment))?

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)