gccgo: SIGSEGV during cgo call #23393
Comments
|
Can you show us a way to reproduce the problem locally? |
|
@ianlancetaylor it's a bit tricky, I'm afraid, because CockroachDB requires gccgo 8+, and one of its dependencies (RocksDB) doesn't compile on GCC 8. Here's one (annoying) way to do it: go get -d github.com/cockroachdb/cockroach
cd $(go env GOPATH)/src/github.com/cockroachdb/cockroach
git remote add tamird github.com/tamird/cockroach && git fetch tamird && git checkout tamird/gccgo
# compile with a non-GCC8 toolchain first to build rocksdb
make build
# compile again with gccgo (rocksdb won't be recompiled)
make build GO=<path to gccgo's go>
# might need to set LD_LIBRARY_PATH
./cockroach start --insecure -s type=mem,size=1GiB
# wait about 10 seconds, some logs will scroll by
<ctrl-c>
<you will see a stack trace beginning with:
initiating graceful shutdown of server
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=1 addr=8 pc=55500911]> |
|
Thanks for the detailed instructions. I've tried a couple of times, and I get this error from |
|
Ah, you need yarn (a node.js package manager) in your $PATH. If that's not
possible, I can look for a workaround.
|
|
Hmmm, I installed a program named "yarn" using |
|
… On Tue, Jan 30, 2018 at 1:22 PM, Ian Lance Taylor ***@***.***> wrote:
Hmmm, I installed a program named "yarn" using apt-get install cmdtest,
but now it looks like it might be the wrong program. man yarn says "yarn
- scenario testing of Unix command line tools". That doesn't sound like
what you are describing. Is there a standard Ubuntu installation of the
tool you are talking about?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#23393 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABdsPFm7R_FWhXnWIStaK89n_YR3oBPHks5tP13KgaJpZM4RYiQV>
.
|
|
I am able to reproduce this on my work machine. I'll poke at it for a bit. |
|
Call stack (partial) at crash from within GDB: At point of crash, we are here: Moving up the stack, it looks as though 'lock' is zero well before we enter the cgo code. |
|
Reproduced as you did using gdb. Here's the a slightly larger stack:
note that we're storing a function literal as a callback to be caller during shutdown - I think gccgo is miscompiling here, such that the closed-over |
|
The value of func lockFile(filename string) (C.DBFileLock, error) {
var lock C.DBFileLock
return lock, statusToError(C.DBLockFile(goToCSlice([]byte(filename)), &lock))
}This looks to me like an order of evaluation problem, similar to what is being discussed right now in #23188. This code is assuming that the call to func lockFile(filename string) (C.DBFileLock, error) {
var lock C.DBFileLock
err := statusToError(C.DBLockFile(goToCSlice([]byte(filename)), &lock))
return lock, err
} |
|
Ah, I think that's correct. I found another issue like this one in a different area of the code. |
|
Confirmed: that change fixes the problem. Closing, and I'll follow the discussion in #23188. |
go version go1.9 gccgo (GCC) 8.0.0 20180108 (experimental) linux/amd64Reproduced by making a
./cockroach quitRPC to a running CockroachDB server compiled with gccgo; the client exited normally, but the server crashed during shutdown.The text was updated successfully, but these errors were encountered: