Closed nicerobot closed 4 years ago
Here's a reproducible test case without the docker requirements. Just clone the gist and run make
.
Seems to be lots of libraries/issues with a similar problem:
https://github.com/libgit2/git2go/issues/334 comment
I suspect this has the same root cause as #373 and #356 where Go's GC decides to free the managed object before we're done with it.
https://github.com/libgit2/git2go/issues/373 https://github.com/libgit2/git2go/pull/387 https://github.com/libgit2/git2go/issues/356 https://github.com/go-gitea/gitea/issues/1408 https://github.com/google/cadvisor/issues/1646 https://github.com/golang/go/issues/17384 https://github.com/golang/go/issues/18429 https://github.com/golang/go/issues/16331#issuecomment-313344965 https://github.com/paulsmith/gogeos/issues/11
@paulsmith from ianlancetaylor
At a quick glance the paulsmith/gogeos package looks risky, as it uses runtime.SetFinalizer but never uses runtime.KeepAlive. See https://golang.org/doc/go1.8#liveness .
I think that the package is correct, but in a usage outside of the package one should be aware of runtime.KeepAlive
Ignore this comment. Go to the update.
I'm sorry that this is going to be very vague but we haven't had the time to investigate too much.
The gist is, we have some gogeos WKT processing that pretty consistently crashes with a
segmentation violation
when compiled using 1.8.1. The same doesn't happen with 1.7.3.The main diagnosis we tried was removing the concurrency, both with code changes and
GOMAXPROCS=1
and various GOGC settings. It still seemed to consistently crash with 1.8.1.We use a Dockerfile to compile the code to ensure that all the dependencies are stable between compilations.
One of the stacks:
The Dockerfile and build:
(the
main.go
in that gist obviously doesn't represent our code which we can't post and haven't had time to create a reproducible case to post)