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

x/playground: Signal 11 from untrusted code #24312

Closed
bendory opened this issue Mar 8, 2018 · 3 comments
Closed

x/playground: Signal 11 from untrusted code #24312

bendory opened this issue Mar 8, 2018 · 3 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unreleased

Comments

@bendory
Copy link
Contributor

bendory commented Mar 8, 2018

https://play.golang.org/p/K4d5dZA58K1 <-- Has a ** Signal 11 from untrusted code: pc=465c000898c0 provoked by line 24.

I initially thought it was the assignment to nil, but line 20 does the same and that line is fine.

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

go1.10 (in the Go playground)

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Go playground

What did you do?

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

What did you expect to see?

I expected the program to print:

go1.10
returned that

What did you see instead?

go1.10

** Signal 11 from untrusted code: pc=4f2f000898c0
@bcmills
Copy link
Contributor

bcmills commented Mar 8, 2018

The error message is definitely wrong, but you don't need all that machinery to reproduce it. Just calling a method on a nil interface will do:
https://play.golang.org/p/J3RPBVxZ8bf

@urld
Copy link
Contributor

urld commented Mar 8, 2018

Correct error message on linux:

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

goroutine 1 [running]:
main.main()
	/home/david/go_ws/src/github.com/urld/foo/main.go:31 +0x2f
exit status 2

This is behaviour is caused by what defer does to named result parameters:

For instance, if the deferred function is a function literal and the surrounding function has named result parameters that are in scope within the literal, the deferred function may access and modify the result parameters before they are returned.
(https://golang.org/ref/spec#Defer_statements)

@andybons andybons changed the title Signal 11 from untrusted code x/playground: Signal 11 from untrusted code Mar 8, 2018
@gopherbot gopherbot added this to the Unreleased milestone Mar 8, 2018
@andybons andybons added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 8, 2018
@andybons andybons self-assigned this Mar 8, 2018
@andybons
Copy link
Member

andybons commented Mar 8, 2018

Duplicate of #23836

@andybons andybons marked this as a duplicate of #23836 Mar 8, 2018
@andybons andybons closed this as completed Mar 8, 2018
@golang golang locked and limited conversation to collaborators Mar 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
5 participants
@andybons @bcmills @gopherbot @urld @bendory