invalid memory address or nil pointer dereference

Question

invalid memory address or nil pointer dereference

bejaneps opened this issue 4 years ago · 10 comments

Hi, I'm getting constant panics with specified error message. By looking at stack trace it's obvious that it's not on my side, because I do check everything to not be nil, before calling any gogm methods. It happens only on session.QueryRaw or session.Query functions. As a note I also check session for nil value before calling any of this functions, but still panics are happening. Please take a look at it, as it's critical bug.

runtime error: invalid memory address or nil pointer dereference

goroutine 155 [running]:
runtime/debug.Stack(0x1, 0x0, 0x0)
	/usr/local/go/src/runtime/debug/stack.go:24 +0x9f
runtime/debug.PrintStack()
	/usr/local/go/src/runtime/debug/stack.go:16 +0x25
panic(0xac42c0, 0xfd92b0)
	/usr/local/go/src/runtime/panic.go:969 +0x1b9
github.com/neo4j/neo4j-go-driver/neo4j.(*result).doFetch(0xc00060fdd0, 0xae28a0)
	/home/bezhan/Programming/go/pkg/mod/github.com/neo4j/neo4j-go-driver@v1.8.1-0.20200622090208-4295b59525c9/neo4j/result.go:73 +0x32
github.com/neo4j/neo4j-go-driver/neo4j.(*result).Next(0xc00060fdd0, 0x1b0)
	/home/bezhan/Programming/go/pkg/mod/github.com/neo4j/neo4j-go-driver@v1.8.1-0.20200622090208-4295b59525c9/neo4j/result.go:96 +0x146
github.com/mindstand/gogm.(*Session).QueryRaw(0xc00008f590, 0xc00071f500, 0x1b0, 0xc000325320, 0x1b0, 0xb2a940, 0xc00032bba0, 0x0, 0x0)

...

This is how I call QueryRaw function and panics happen:

if sess == nil {
    return
}
sess.QueryRaw("MATCH ...", map[string]interface{}{}) // panic happens on this line

Answer 1 · 2020-10-27T22:33:47.000Z

Hi bejaneps,
Thank you for letting us know about this bug. Could you tell me a bit more about the issue, including some details about your gogm.Config (are you in cluster mode & your specified pool size), any registered models & any details about queries that have caused failures.

Are these failures intermittent? Or do specific queries reliably cause the panic?

Thanks again,
Nikita

Answer 2 · 2020-10-27T22:45:49.000Z

Also, do you know what version of Neo4j you're using? We have only tested GoGM with Neo4J version 3.x and 4.x

Between this issue and #45 you have definitely surprised us with some unexpected errors!

Answer 3 · 2020-10-27T23:22:47.000Z

Hi, thanks for quick reply. This is my config:

gogm.Config{
	IndexStrategy: gogm.VALIDATE_INDEX,
	PoolSize:      50,
	IsCluster:     false,
}

Models that I'm using are as follows:

type UnitOfMeasureRegion struct {
	gogm.BaseNode

	Name          string `gogm:"name=name"`
	EndVersion    int64  `gogm:"name=endVersion"`
	UniqID string `gogm:"name=uniqID"`
	StartVersion  int64  `gogm:"name=startVersion"`
}

type Sensor struct {
	gogm.BaseNode

	SensorHardwareModel string      `gogm:"name=sensorHardwareModel"`
	SensorMaker         string      `gogm:"name=sensorMaker"`
	UniqID       string      `gogm:"name=uniqID"`
	SensorGranularity   string      `gogm:"name=sensorGranularity"`
	StartVersion        int64       `gogm:"name=startVersion"`
	RangeMin            int64       `gogm:"name=rangeMin"`
	OptimalMax          interface{} `gogm:"name=optimalMax"`
	ExpectedMax         int64       `gogm:"name=expectedMax"`
	SensorOperatingMax  interface{} `gogm:"name=sensorOperatingMax"`
	SensorError         interface{} `gogm:"name=sensorError"`
	SensorID            string      `gogm:"name=sensorID"`
	RangeMax            int64       `gogm:"name=rangeMax"`
	SensorResolution    interface{} `gogm:"name=sensorResolution"`
	OptimalMin          int64       `gogm:"name=optimalMin"`
	SeID                string      `gogm:"name=seId"`
	Name                string      `gogm:"name=name"`
	EndVersion          int64       `gogm:"name=endVersion"`
	SensorOperatingMin  int64       `gogm:"name=sensorOperatingMin"`
	SensorUnit          string      `gogm:"name=sensorUnit"`
	ExpectedMin         int64       `gogm:"name=expectedMin"`
}

// ReferenceObject is a reference type that is a reference to neo4j object
type ReferenceObject struct {
	gogm.BaseNode

	UniqID        string      `gogm:"name=uniqID"`
	EndReferencePeriod   interface{} `gogm:"name=endReferencePeriod"`
	BeginReferencePeriod interface{} `gogm:"name=beginReferencePeriod"`
	StartVersion         int64       `gogm:"name=startVersion"`
	Name                 string      `gogm:"name=name"`
	EndVersion           int64       `gogm:"name=endVersion"`
	CanonicalValuesNames []string    `gogm:"name=canonicalValuesNames;properties"`
	FieldsNames          []string    `gogm:"name=fieldsNames;properties"`
	TableName            string      `gogm:"name=tableName"`
}

Queries that cause failures are as follow:

MATCH (n:ReferenceInstantValue {name:"{{.ReferenceObject.Name}}", beginReferencePeriod:"{{.ReferenceObject.BeginReferencePeriod}}", endReferencePeriod:"{{.ReferenceObject.EndReferencePeriod}}", uniqID:"{{.ReferenceObject.UniqID}}"})-[:PROVIDED_BY]->(sensor) WHERE sensor.name="{{.Sensor.Name}}" RETURN n.uniqID, n.endReferencePeriod, n.beginReferencePeriod, n.startVersion, n.name, n.endVersion, n.canonicalValuesNames, n.fieldsNames, n.tableName LIMIT 1

MATCH (n:ReferenceInstantValue {name:"{{.ReferenceObject.Name}}", beginReferencePeriod:"{{.ReferenceObject.BeginReferencePeriod}}", endReferencePeriod:"{{.ReferenceObject.EndReferencePeriod}}", uniqID:"{{.ReferenceObject.UniqID}}"}) RETURN n LIMIT 1

NOTE: failures are random, sometimes they happen for same queries, sometimes not, so can't say for sure if it's just happening for a specific query

Neo4j Version: 3.5
Go Version: 1.15.3
OS: Linux

Answer 4 · 2020-10-27T23:31:12.000Z

Adding 2 more errors to the stack that happen time to time from running above queries:

Invalid state 6, expected: [1 4]"
Failed to parse RUN response: &{meta:map[bookmark:neo4j:bookmark:v1:tx1494022 t_last:0 type:r]}"

Answer 5 · 2020-10-27T23:36:31.000Z

1 more panic with a bit different message:

runtime error: invalid memory address or nil pointer dereference

goroutine 399 [running]:
runtime/debug.Stack(0x1, 0x0, 0x0)
	/usr/local/go/src/runtime/debug/stack.go:24 +0x9f
runtime/debug.PrintStack()
	/usr/local/go/src/runtime/debug/stack.go:16 +0x25
panic(0xac5280, 0xfdb2b0)
	/usr/local/go/src/runtime/panic.go:969 +0x1b9
github.com/neo4j/neo4j-go-driver/neo4j.(*result).doFetch(0xc00019ed80, 0xc0001a2000)
	/home/bezhan/Programming/go/pkg/mod/github.com/neo4j/neo4j-go-driver@v1.8.1-0.20200622090208-4295b59525c9/neo4j/result.go:73 +0x32
github.com/neo4j/neo4j-go-driver/neo4j.(*result).fetchAll(0xc00019ed80)
	/home/bezhan/Programming/go/pkg/mod/github.com/neo4j/neo4j-go-driver@v1.8.1-0.20200622090208-4295b59525c9/neo4j/result.go:134 +0x39
github.com/neo4j/neo4j-go-driver/neo4j.(*session).consumeCurrent(0xc0001319a0, 0x203000, 0xa8ffa0)
	/home/bezhan/Programming/go/pkg/mod/github.com/neo4j/neo4j-go-driver@v1.8.1-0.20200622090208-4295b59525c9/neo4j/session.go:419 +0x34
github.com/neo4j/neo4j-go-driver/neo4j.(*session).Run(0xc0001319a0, 0xc00048a000, 0x1b0, 0xc0005a8180, 0x0, 0x0, 0x0, 0x40ef01, 0xc00060a180, 0xc0000b9118, ...)
	/home/bezhan/Programming/go/pkg/mod/github.com/neo4j/neo4j-go-driver@v1.8.1-0.20200622090208-4295b59525c9/neo4j/session.go:436 +0x4f
github.com/mindstand/gogm.runWrap.func1(0xc00048a000, 0x1b0, 0xc0005a8180, 0x30, 0x30, 0x7f1b27d3e108, 0xc0005a8180)
	/home/bezhan/Programming/go/pkg/mod/github.com/mindstand/gogm@v1.4.0/save.go:43 +0xfe
github.com/mindstand/gogm.(*Session).QueryRaw(0xc0001a5290, 0xc00048a000, 0x1b0, 0xc0005a8180, 0x1b0, 0xb2b900, 0xc00060a160, 0x0, 0x0)

Answer 6 · 2020-10-28T18:32:29.000Z

Hi again, we've tried replicating the issues you've reported, and have determined that it's likely an internal issue with the go driver. We've contacted neo4j's driver team for help as well.

A lot of your issues seem to be connection related, have you been able to reproduce the errors running locally vs. on some external server?

Answer 7 · 2020-11-01T21:03:51.000Z

Hey, sorry for replying late, was busy lately debugging my code. I've done testing locally, but used remote neo4j cluster not local one. If you need more details, please ask me and I will be happy to help you.

Answer 8 · 2020-11-08T23:51:25.000Z

Hi, wanted to know if there are any updates on this issue ? I can reproduce issue better if you need, just tell what specifically you need for understanding underlying problem.

Answer 9 · 2020-11-17T06:49:03.000Z

@bejaneps how are you using Go threads? Neither gogm session or the underlying driver session are designed to be accessed from multiple Go threads. For example if you are serving http requests you cannot share session instance between handler functions.

Answer 10 · 2020-11-17T12:40:03.000Z

Hi again, I switched to gogm version v1.5.0 and neo4j-go-driver v1.8.3 and I can confirm that all errors and panics are gone. I don't know what is the reason behind that, but it seems in that version this bugs are fixed.