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

cmd/compile: incorrect stack trace for nil dereference in inlined function #27201

Closed
robfig opened this issue Aug 24, 2018 · 3 comments
Closed
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@robfig
Copy link
Contributor

robfig commented Aug 24, 2018

I believe that the stack trace for panics that occur when computing arguments to an inlined function are incorrectly attributed to the inlined function. I'm not sure if this is a known / expected consequence of inlining, but it caused a lot of confusion to see a line identified where a nil dereference is impossible.

What version of Go are you using (go version)?

Go 1.10.3

Does this issue reproduce with the latest release?

Yes, it still exists in Go 1.11rc1

What did you do?

https://play.golang.org/p/V5EzYYYSDjz

What did you expect to see?

A panic with this stack trace, identifying the line of the nil dereference:

goroutine 1 [running]:
main.main()
	/tmp/sandbox722989325/main.go:10 +0x1a

What did you see instead?

Incorrect attribution to an innocent function.

goroutine 1 [running]:
main.helperCall(...)
	/tmp/sandbox722989325/main.go:14
main.main()
	/tmp/sandbox722989325/main.go:10 +0x1a
@ianlancetaylor ianlancetaylor changed the title Incorrect Stack Trace cmd/compile: incorrect stack trace for nil dereference in inlined function Aug 24, 2018
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 24, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Aug 24, 2018
@randall77
Copy link
Contributor

Not sure what's going on here. Something with the inlining records, presumably.
The assembly instruction that does the nil dereference has the correct line number:

	0x001f 00031 (/Users/khr/gowork/issue27201.go:10)	MOVLQSX	(AX), AX

@davidlazar

@odeke-em odeke-em self-assigned this Oct 18, 2018
@randall77
Copy link
Contributor

I see what is happening now.

My last comment was incorrect, the MOVLQSX is indeed marked at line 14.
(My CL to change -S to report the innermost line number makes that obvious now.)

What's happening here is that two instructions are being merged, and the choice of line number is pretty arbitrary:

v7 (10) = Load <int32> v6 v1 (a[int32])
v10 (+14) = SignExt32to64 <time.Duration> v7 (~r1[time.Duration])

gets merged to

v45 (+14) = MOVLQSXload <time.Duration> v4 v1

Note that the load is line 10 and the sign extension is line 14. That's correct. The merged instruction ends up at line 14. That's not incorrect, but maybe not super helpful. In particular, I think the line number of the load (or any possibly faulting instruction really) should supercede the line number of the sign extension.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/156937 mentions this issue: cmd/compile: when merging instructions, prefer line number of faulting insn

@golang golang locked and limited conversation to collaborators Jan 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge 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

5 participants