Michael Pratt

New patches, now based on the 1.18 release branch, so they should apply cleanly: * https://go.dev/cl/424076: Identical to https://go.dev/cl/424195. * https://go.dev/cl/424077: Similar to https://go.dev/cl/424196. Adds the previous frame to the...

It's possible, though I'm surprised there is no further indication of crash if true. Do you see ["stack trace unavailable"](https://cs.opensource.google/go/go/+/master:src/runtime/panic.go;l=1228;drc=d09c6ac41769cc782ec982ffc8f20fbd796791f8) at the end? Curiously, I've been using the same patch...

> I'm still puzzled by the unaligned-PC-like values, e.g. 0x11b2b I was confused by those as well. There are some really odd ones like `runtime.debugCallWrap.func1`. My guess was that since...

> What's also odd is that the kubectl log output stops after a small number of goroutines Huh. I'd noticed that your logs stop at the second goroutine header and...

Awesome, thanks! Here's what I see: Caveat: The debuglog is still a bit corrupted, I guess because I printed early while other threads were still writing to it. That's OK...

> ``` > TEXT github.com/honeycombio/libhoney-go.(*Client).AddField(SB) > ``` This is `Client.AddField`. Could you post `fieldHolder.AddField`? Also for `0x7cdc0`, it looks like you posted `0x7cdc00` instead (off by an order of magnitude)....

Thanks! Could you also see the disassembly for `0x7d000` and `0x355e44` in traceback 4?

I wonder if https://github.com/google/pprof/pull/689 will address this. I’m skeptical though, as bad escaping should most likely cause parse errors.

No, this seems to be different. In pprof, the type name is `main.Set[...]` in my test (your package is named `mak`, right?). pprof or dot (not sure where this lives)...

There is an even worse case with `pkg.(*T[...]).f` turning into `pkg..f`, even in the text view. Both of these are covered by https://github.com/google/pprof/issues/705.