I'm trying to debug leaking goroutines (using Gomega's gleak). When at the end of a unit test some goroutines "stubbornly" persist to not terminate, gleak dumps the culprits with their stack traces. Some calls in these stack traces contain even several question marks in their arguments or return values, such as:

foo.(*Fooler).Foo(0x40003efa40, {0xeeb638?, 0x40005bc580}, {0x400013a000?, 0x6, 0xd9c3a4?}) at foo.go

the corresponding receiver function signature is as follows:

func (f *Fooler) Foo(context.Context, []string)

I've checked several posts/articles/questions on "interpreting golang stack traces", not least How to interpret Go stacktrace, but didn't find any mentioning of question marks in Go stack traces. The examples I find explained never mention any questionable(?) call arguments or return values.

So what is the reason for question marks in stack traces? Could this be related to args passed in registers and not properly recoverable for the stack trace?

CodePudding user response：

From https://go.dev/doc/go1.18#runtime :

Go 1.17 generally improved the formatting of arguments in stack traces, but could print inaccurate values for arguments passed in registers. This is improved in Go 1.18 by printing a question mark (?) after each value that may be inaccurate.