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: defer in shared library on 386 panics #15916

Closed
mwhudson opened this issue Jun 1, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@mwhudson
Copy link
Contributor

commented Jun 1, 2016

Please answer these questions before submitting your issue. Thanks!

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

1.6

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

linux/386

  1. What did you do?
(master)mwhudson@aeglos:/opt/opensource/go/src$ cat $GOPATH/src/t1/t1.go
package t1

func F() {
    defer func() {}()
}
(master)mwhudson@aeglos:/opt/opensource/go/src$ cat /opt/opensource/go-test-cases/triv1.go
package main

import "t1"

func main() {
    t1.F()
}
(master)mwhudson@aeglos:/opt/opensource/go/src$ go install -buildmode=shared std
(master)mwhudson@aeglos:/opt/opensource/go/src$ go install -linkshared -buildmode=shared t1
(master)mwhudson@aeglos:/opt/opensource/go/src$ go run -linkshared /opt/opensource/go-test-cases/triv1.go
  1. What did you expect to see?

no output

  1. What did you see instead?
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]

goroutine 1 [running]:
panic(0xf74d3c80, 0xd6512018)
    /opt/opensource/go/src/runtime/panic.go:500 +0x59a
t1.F()
    /opt/opensource/gopath/src/t1/t1.go:5 +0x52
main.main()
    /opt/opensource/go-test-cases/triv1.go:6 +0x23
exit status 2

I was sure there was a test for this, but there is only one for using defer in a dynamically linked executable, not a shared object. No idea what the issue is yet.

@mwhudson

This comment has been minimized.

Copy link
Contributor Author

commented Jun 1, 2016

Ah, think the test case might be a red herring, and it's actually that the inserted call to morestack is not following the ABI rules properly (in which case I'm surprised anything works at all, but...)

@gopherbot

This comment has been minimized.

Copy link

commented Jun 2, 2016

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

@gopherbot gopherbot closed this in 2684974 Jun 3, 2016

@golang golang locked and limited conversation to collaborators Jun 3, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.