runtime: unexpected signal during runtime execution in Go 1.17 but not Go 1.16 #46763
Comments
|
The go 1.16 example is using linux inside docker. The 1.17 example looks like it was running on Darwin. Is it possible to eliminate Darwin as a factor? |
seankhliao
added
the
WaitingForInfo
|
@davecheney good call. It looks like this is only reproducible in Macs: $ docker run --rm -it -v `pwd`:/app golang:1.17beta1
$ cd /app && go run .
go: downloading github.com/sirupsen/logrus v1.8.1
go: downloading github.com/lightstep/lightstep-tracer-go v0.25.0
go: downloading golang.org/x/sys v0.0.0-20210217105451-b926d437f341
go: downloading github.com/gogo/protobuf v1.3.2
go: downloading github.com/lightstep/lightstep-tracer-common/golang/gogo v0.0.0-20210210170715-a8dfcb80d3a7
go: downloading github.com/opentracing/opentracing-go v1.0.2
go: downloading google.golang.org/grpc v1.21.0
go: downloading github.com/shirou/gopsutil/v3 v3.21.2
go: downloading golang.org/x/net v0.0.0-20201021035429-f5854403a974
go: downloading google.golang.org/genproto v0.0.0-20190530194941-fb225487d101
go: downloading github.com/tklauser/go-sysconf v0.3.4
go: downloading github.com/golang/protobuf v1.3.1
go: downloading github.com/tklauser/numcpus v0.2.1
go: downloading golang.org/x/text v0.3.3
INFO[0000] helloDo note, however, that this is still a 1.17 bug because Go 1.16 on macs still works with the above program. I was able to reproduce this by doing the following: $ docker run --rm -it -v `pwd`:/app golang:1.16
$ cd /app
$ GOOS=darwin go build
$ Ctrl+C # to exit container and run volume'd mac binary
$ ./main
INFO[0000] helloPlus this is an extraction of an internal repository and I had been using Go1.16 to build it for a while and the error did not occur. Thanks! |
|
@marwan-at-work the |
|
@mark-rushakoff that sounds great. However, I still find it odd that the same x/sys module@version works in Go1.16 but not in 1.17. Typically, upgrading a minor Go version means your program should continue to work. In this case, someone in my situation will need to realize that upgrading from Go 1.16 to Go 1.17 is a bit of a breaking change because they will also need to upgrade an underlying dependency which may not be an option for them. Luckily for me, I'm happy to upgrade x/sys but just thought I'd point it out. Thanks again for the quick responses ✌🏼 |
|
The previous version of x/sys use some assembly code in a subtle way that happens to work with Go 1.16 but not with 1.17 (this is not covered by the compatibility guarantee). As commented previously, updating to a newer version of x/sys works. Closing. Thanks. |
See: golang/go#46763 Co-authored-by: Yasar Alev <semihalev@gmail.com>
This commit fixes the issue: mattn/go-isatty@ee4b64c Details on the issue: golang/go#46763
This commit fixes the issue: mattn/go-isatty@ee4b64c Details on the issue: golang/go#46763
This commit fixes the issue: https://github.com/mattn/go-isatty@ee4b64c Details on the issue: golang/go#46763
This commit fixes the issue: mattn/go-isatty@ee4b64c Details on the issue: golang/go#46763
Mainly to update x/sys so that the program doesn't segfault when built with go 1.17. See golang/go#46763.
See golang/go#46763. The CLI would error at runtime after being compiled with go 1.17, unless the x/sys dependency is bumped.
See golang/go#46763. The CLI would error at runtime after being compiled with go 1.17, unless the x/sys dependency is bumped.
This commit fixes the issue: mattn/go-isatty@ee4b64c Details on the issue: golang/go#46763
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes for 1.17 no for latest stable release (1.16)
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
The steps are quite reproducible:
Add the following main.go file:
What did you expect to see?
In Go 1.16 things work fine:
What did you see instead?
The segment violation mentioned above.
Note that only when I added the lightstep tracer above did the runtime panic occur. It is probably due to enforcement of an underlying dependency namely golang.org/x/sys.
If I upgrade the underlying dependency (though I've never directly used it), it actually ends up working. To be specific:
This works:
golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1This does not work:
golang.org/x/sys v0.0.0-20210217105451-b926d437f341 // indirectHowever, in 1.16, both work fine. Which is why I think this is more of a Go bug rather than a library bug.
Thanks!
The text was updated successfully, but these errors were encountered: