Skip to content

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

Closed
@griesemer

Description

@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

Activity

randall77

randall77 commented on Jan 24, 2014

@randall77
Contributor

Comment 1:

Dmitry, you can take this one if you'd like.
added this to the Unplanned milestone on Apr 10, 2015
gopherbot

gopherbot commented on Feb 18, 2017

@gopherbot
Contributor

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

odeke-em

odeke-em commented on Feb 18, 2017

@odeke-em
Member
gopherbot

gopherbot commented on Oct 15, 2017

@gopherbot
Contributor

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

gopherbot

gopherbot commented on Oct 15, 2017

@gopherbot
Contributor

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

odeke-em

odeke-em commented on Oct 15, 2017

@odeke-em
Member

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

12 remaining items

gopherbot

gopherbot commented on Nov 9, 2020

@gopherbot
Contributor

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 commented on Nov 9, 2020

@randall77
Contributor

CL was reverted.

jordan-bonecutter

jordan-bonecutter commented on Jul 15, 2021

@jordan-bonecutter

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

gopherbot

gopherbot commented on Feb 9, 2023

@gopherbot
Contributor

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

gopherbot

gopherbot commented on Mar 13, 2023

@gopherbot
Contributor

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

locked and limited conversation to collaborators on Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

FrozenDueToAgeNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.help wanted

Type

No type

Projects

No projects

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @bradfitz@rsc@ianlancetaylor@odeke-em@randall77

      Issue actions

        runtime: stack traces of endless recursion should print top and bottom · Issue #7181 · golang/go