You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We saw the same panic when either running with a Darwin build, or running on Linux with a build cross compiled from Darwin.
What did you do?
This setup process is slightly involved. I tried to capture all the relevant details on the first pass here; but I'm eager to get this fixed, so I'll try and respond quickly if there's any trouble reproducing the issue.
If you want to go through building from source to reproduce the crash:
go get github.com/sparrc/gdm # dependency management tool we use
go get -d github.com/influxdata/influxdb
cd $GOPATH/src/github.com/influxdata/influxdb
$GOPATH/bin/gdm restore # Configures dependencies into $GOPATH
go run cmd/influxd/main.go
# Alternatively, cross compiled with:
# GOBIN="" GOOS=linux GOARCH=amd64 go install ./...
On OSX, we've seen the crash with and without SSA enabled. We didn't try linux without SSA.
In a separate shell, run this load generator against the influxdb instance. It reliably (>80% of the time?) panics within the first iteration of the tool, which completes in around 30 seconds.
What did you expect to see?
No panic. The offending part of the stack trace looks like it may be susceptible to a nil pointer dereference, but Go should prevent a segfault, right?
No panic. The offending part of the stack trace looks like it may be susceptible to a nil pointer dereference, but Go should prevent a segfault, right?
No. Not right.
I see no evidence that this isn't a bug in InfluxDB.
It was the line [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x5fa88f] that caused me to believe we ran into a bug with Go. I've just confirmed in a separate test that this format is the normal format in Go 1.7.
Closing this issue now and assuming it's a bug on our end.
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?We saw the same panic when either running with a Darwin build, or running on Linux with a build cross compiled from Darwin.
What did you do?
This setup process is slightly involved. I tried to capture all the relevant details on the first pass here; but I'm eager to get this fixed, so I'll try and respond quickly if there's any trouble reproducing the issue.
If you don't want to go through building and running InfluxDB, we have a 206MB gzipped core dump from linux/amd64, running with
GOTRACEBACK=crash
, and the corresponding binary, built from influxdata/influxdb@7e515cf.If you want to go through building from source to reproduce the crash:
On OSX, we've seen the crash with and without SSA enabled. We didn't try linux without SSA.
In a separate shell, run this load generator against the influxdb instance. It reliably (>80% of the time?) panics within the first iteration of the tool, which completes in around 30 seconds.
What did you expect to see?
No panic. The offending part of the stack trace looks like it may be susceptible to a nil pointer dereference, but Go should prevent a segfault, right?
What did you see instead?
Panic starting with:
Full panic attached: panic.txt
The text was updated successfully, but these errors were encountered: