runtime: stack traces of endless recursion should print top and bottom

[griesemer]

In stack traces caused by endless recursion it would be a lot more useful to print the n
top-most and the n bottom-most frames rather than just the top ones. Ideally, I'd like
to see something like (fake stack trace):

runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow

goroutine 38 [stack split]:
copyout(0x25c3e0, 0x2251d0a148, 0x2251d0a150)
    /Users/gri/go/src/pkg/runtime/iface.c:160 fp=0x2251d0a100
runtime.assertI2T2(0x25c3e0, 0x221065d900, 0x2112a7dc0, 0x0, 0x1)
    /Users/gri/go/src/pkg/runtime/iface.c:268 +0x59 fp=0x2251d0a138
code.google.com/p/go.tools/go/types.WriteType(0x210de8bd0, 0x0, 0x221065d900,
0x2112a7dc0)
    /Users/gri/golib/src/code.google.com/p/go.tools/go/types/typestring.go:58 +0x5f2 fp=0x2251d0a2d0
code.google.com/p/go.tools/go/types.WriteType(0x210de8bd0, 0x0, 0x221065d9f0,
0x210ea3bd0)
    /Users/gri/golib/src/code.google.com/p/go.tools/go/types/typestring.go:95 +0x803 fp=0x2251d0a468
code.google.com/p/go.tools/go/types.WriteType(0x210de8bd0, 0x0, 0x221065d900,
0x2112a7dc0)

... (1234 stack frames omitted)

    /Users/gri/golib/src/code.google.com/p/go.tools/go/types/typestring.go:104 +0x670 fp=0x2251d0a600
code.google.com/p/go.tools/go/types.WriteType(0x210de8bd0, 0x0, 0x221065d9f0,
0x210ea3bd0)
    /Users/gri/golib/src/code.google.com/p/go.tools/go/types/typestring.go:95 +0x803 fp=0x2251d0a798
code.google.com/p/go.tools/go/types.WriteType(0x210de8bd0, 0x0, 0x221065d900,
0x2112a7dc0)
    /Users/gri/golib/src/code.google.com/p/go.tools/go/types/typestring.go:104 +0x670 fp=0x2251d0a930
code.google.com/p/go.tools/go/types.WriteType(0x210de8bd0, 0x0, 0x221065d9f0,
0x210ea3bd0)
    /Users/gri/golib/src/code.google.com/p/go.tools/go/types/typestring.go:95 +0x803 fp=0x2251d0aac8
code.google.com/p/go.tools/go/types.WriteType(0x210de8bd0, 0x0, 0x221065d900,
0x2112a7dc0)
    /Users/gri/golib/src/code.google.com/p/go.tools/go/types/typestring.go:104 +0x670 fp=0x2251d0ac60
code.google.com/p/go.tools/go/types.WriteType(0x210de8bd0, 0x0, 0x221065d9f0,
0x210ea3bd0)
    /Users/gri/golib/src/code.google.com/p/go.tools/go/types/typestring.go:95 +0x803 fp=0x2251d0adf8
code.google.com/p/go.tools/go/types.WriteType(0x210de8bd0, 0x0, 0x221065d900,
0x2112a7dc0)
    /Users/gri/golib/src/code.google.com/p/go.tools/go/types/typestring.go:104 +0x670 fp=0x2251d0af90
code.google.com/p/go.tools/go/types.WriteType(0x210de8bd0, 0x0, 0x221065d9f0,
0x210ea3bd0)
    /Users/gri/golib/src/code.google.com/p/go.tools/go/types/typestring.go:95 +0x803 fp=0x2251d0b128
created by testing.RunTests
    /Users/gri/go/src/pkg/testing/testing.go:471 +0x978

goroutine 16 [chan receive]:
testing.RunTests(0x2f1680, 0x596ce0, 0x1a, 0x1a, 0x0)
    /Users/gri/go/src/pkg/testing/testing.go:472 +0x9a8
testing.Main(0x2f1680, 0x596ce0, 0x1a, 0x1a, 0x59ba80, ...)
    /Users/gri/go/src/pkg/testing/testing.go:403 +0x8c
main.main()
    /var/folders/00/013yr000h01000cxqpysvccm0004gv/T/go-build006333714/code.google.com/p/go.tools/go/types/_test/_testmain.go:99 +0x9c
exit status 2

[randall77]

Comment 1:

Dmitry, you can take this one if you'd like.

[gopherbot]

CL https://golang.org/cl/37222 mentions this issue.

[odeke-em]

I've hacked up https://go-review.googlesource.com/c/37222.

[gopherbot]

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

[gopherbot]

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

[odeke-em]

Sorry for all the spamming with the CL notifications, Gerrit was tripping out on me and instead got me mailing triplicate CLs.

[dtarico-suplari]

Any way to vote on this? Our dev team just spent a day trying to guess which part of our code might have been in the stack because our entire codebase was elided from the trace.

encoding/json.ptrEncoder.encode-fm(0xc018fd8000, 0x100b860, 0xc0004164f0, 0x16, 0xc0ad700100)
/usr/local/go/src/encoding/json/encode.go:801 +0x64 fp=0xc165342c30 sp=0xc165342bf0 pc=0x757604
...additional frames elided...
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2884 +0x2f4

[randall77]

Any way to vote on this?

Thumbs up on initial post.

I think we're happy to have this done. It's just that no one has yet signed up to do it.

[odeke-em]

I signed up to fix it :) but there is a blocker bug within the runtime about the skips that were changed and that issue isn’t yet fixed. I mailed a CL but that CL is in limbo until that issue is resolved. I’ll nudge Austin and Michael perhaps in the Go1.15 cycle, so thanks for the ping and apologies for the stall.

…

On Mon, Jan 6, 2020 at 8:17 PM Keith Randall ***@***.***> wrote: Any way to vote on this? Thumbs up on initial post. I think we're happy to have this done. It's just that no one has yet signed up to do it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7181?email_source=notifications&email_token=ABFL3VZZ4RETFGW56UQW4DTQ4P64PA5CNFSM4DAUJV72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIHUJQI#issuecomment-571425985>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFL3V7G7GVQ6O5FARGW3KDQ4P64PANCNFSM4DAUJV7Q> .

[griesemer]

I'm going to mark this for 1.15 so it receives some visibility. This will be very helpful whenever an endless recursion strikes. We can always put it back on backlog.

[gopherbot]

Change https://golang.org/cl/268517 mentions this issue: runtime: use calculated limits instead of 1<<31-1 as max for printing tracebacks

[randall77]

CL was reverted.

[jordan-bonecutter]

Is this still planned? Would be super nice...

[gopherbot]

Change https://go.dev/cl/458218 mentions this issue: runtime: implement traceback iterator

[gopherbot]

Change https://go.dev/cl/475960 mentions this issue: runtime: for deep stacks, print both the top 50 and bottom 50 frames