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

Jump to bottom

runtime: crash shows autogenerated type parameters #48578

Closed
rsc opened this issue Sep 23, 2021 · 4 comments
Closed

runtime: crash shows autogenerated type parameters #48578

rsc opened this issue Sep 23, 2021 · 4 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone
Go1.18

Comments

@rsc
Copy link
Contributor

rsc commented Sep 23, 2021

I have a parameterized type named Treap[K, V].
Here's a crash:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x108e2e5]

goroutine 1 [running]:
math/big.(*Int).Cmp(0x30, 0x10aee80)
	/Users/rsc/go/src/math/big/int.go:328 +0x25
main.(*Treap[.shape.*uint8_0,.shape.*uint8_1]).Get(0x10d7ec0, 0xc0000c0570, 0xc0000d7d40)
	/Users/rsc/complex.go:145 +0x7b
main.explore(0x10d6500, 0xc0000ae008, 0x10b7929)
	/Users/rsc/complex.go:73 +0x4b
main.main()
	/Users/rsc/complex.go:51 +0x585

Note the main.(*Treap[.shape.*uint8_0,.shape.*uint8_1]).Get.

I understand why the name is needed in the binary, but it's not a great name to see in the stack trace.
It seems like we should probably elide that part, as in main.(*Treap[...]).Get,
or else make it more readable somehow.

/cc @randall77 @danscales
@rsc rsc added NeedsFix The path to resolution is known, but the work has not been done. release-blocker labels Sep 23, 2021
@rsc rsc added this to the Go1.18 milestone Sep 23, 2021
@danscales
Copy link
Contributor

Seems like a good suggestion.

I think this might be the first case where we slightly change a function name in a backtrace, rather than completely omit the function entry (as with wrappers). I guess maybe we can use the '...' as a good indication that the user that the name is not exactly what is in the binary (i.e. the user will see something different if they debug the crash in gdb). Or maybe we can think of some further way to highlight the change (something at the beginning of the line?).

@randall77
Copy link
Contributor

If we had access to the dictionary we could print the real type(s) the code is instantiated with, as if it was fully stenciled. That could be tough, though, as we'd need to keep the dictionary reference alive and in a known location.

@gopherbot
Copy link

Change https://golang.org/cl/352118 mentions this issue: runtime: elide instantiated types in tracebacks

@gopherbot
Copy link

Change https://golang.org/cl/352119 mentions this issue: cmd/compile: leave dictionary argument out of traceback argument list

gopherbot pushed a commit that referenced this issue Sep 27, 2021
@randall77
cmd/compile: leave dictionary argument out of traceback argument list
315cec2 
The dictionary argument is implicit; the user doesn't need to see it.

Update #48578

Change-Id: I367ba4b6622119d3e01aaded90463d16823915a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/352119
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
@golang golang locked and limited conversation to collaborators Sep 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
4 participants
@rsc @danscales @randall77 @gopherbot