Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
griesemer opened this issue Jan 22, 2014 · 15 comments
Closed
Assignees
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@griesemer
Copy link
Contributor

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
Copy link
Contributor

Comment 1:

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

@bradfitz bradfitz removed the new label Dec 18, 2014
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@gopherbot
Copy link

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

@odeke-em
Copy link
Member

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

@gopherbot
Copy link

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

@gopherbot
Copy link

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

@odeke-em
Copy link
Member

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

@dtarico-suplari
Copy link

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
Copy link
Contributor

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.

@griesemer griesemer modified the milestones: Unplanned, Go1.15 Jan 7, 2020
@odeke-em
Copy link
Member

odeke-em commented Jan 7, 2020 via email

@griesemer
Copy link
Contributor Author

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.

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 18, 2020
@ianlancetaylor ianlancetaylor modified the milestones: Go1.15, Backlog May 18, 2020
@odeke-em odeke-em self-assigned this Jun 7, 2020
@gopherbot
Copy link

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

@randall77 randall77 reopened this Nov 9, 2020
@randall77
Copy link
Contributor

CL was reverted.

@jordan-bonecutter
Copy link

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

@gopherbot
Copy link

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

gopherbot pushed a commit that referenced this issue Mar 10, 2023
Currently, all stack walking logic is in one venerable, large, and
very, very complicated function: runtime.gentraceback. This function
has three distinct operating modes: printing, populating a PC buffer,
or invoking a callback. And it has three different modes of unwinding:
physical Go frames, inlined Go frames, and cgo frames. It also has
several flags. All of this logic is very interwoven.

This CL reimplements the monolithic gentraceback function as an
"unwinder" type with an iterator API. It moves all of the logic for
stack walking into this new type, and gentraceback is now a
much-simplified wrapper around the new unwinder type that still
implements printing, populating a PC buffer, and invoking a callback.
Follow-up CLs will replace uses of gentraceback with direct uses of
unwinder.

Exposing traceback functionality as an iterator API will enable a lot
of follow-up work such as simplifying the open-coded defer
implementation (which should in turn help with #26813 and #37233),
printing the bottom of deep stacks (#7181), and eliminating the small
limit on CPU stacks in profiles (#56029).

Fixes #54466.

Change-Id: I36e046dc423c9429c4f286d47162af61aff49a0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/458218
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
@gopherbot
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

9 participants