runtime: gentraceback no longer skips stack frames when printing

[odeke-em]

I got some time today to finish up and add a rigorous test for CL https://go-review.googlesource.com/#/c/go/+/37222 which involves printing the top and bottom n frames for easy reading in case of a massive stackoverflow.

To detect that we are printing stackframes, we have this condition

go/src/runtime/traceback.go

Line 142 in fdf3373

printing := pcbuf == nil && callback == nil

and in order for it to work, we need to be able to skip a bunch of frames when printing the bottom n stack frames.

However, with code that we used to skip through physical frames previously, CL https://go-review.googlesource.com/37854 aka commit ee97216 changed that behavior assuming that we'd never use skip unless pcbuf != nil. However, we actually need to skip through physical frames when printing tracebacks otherwise on trying to print top and bottom stackframes, we always end up printing the top irrespective of our skip which is a regression that silently snuck in for an entire year as it wasn't used.

The code that disabled proper skipping is ee97216#diff-5a2de8a1053d4e11fbc71407a5361e93L321

/cc @davidlazar @aclements

[bcmills]

Is this a regression in a user-facing behavior, or just an internal function?

(I assume that it's blocking #7181; is that the only impact?)

[odeke-em]

@bcmills correct, it is only blocking #7181, but nonetheless a bug when skipping and printing -- something that hasn't yet been exposed though because we've been printing the entirety of stackframes.

[gopherbot]

Change https://golang.org/cl/37222 mentions this issue: runtime: stack traces of endless recursion now print top and bottom

[odeke-em]

I've mailed a fix for this issue, packaged in the the CL that it was blocking as per https://go-review.googlesource.com/c/go/+/37222.

[randall77]

CL was reverted.