Open object88 opened 6 years ago
Example steps to show problem:
Error log looks something like:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x14aba3c]
goroutine 1872 [running]:
github.com/object88/langd.(*Workspace).LocateDeclaration.func1(0x1904ba0, 0xc42092f920, 0x12698)
/Users/bropa18/work/src/github.com/object88/langd/workspace.go:183 +0x36c
go/ast.inspector.Visit(0xc43df39e20, 0x1904ba0, 0xc42092f920, 0x23, 0xc420db9770)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:373 +0x3a
go/ast.Walk(0x1901be0, 0xc43df39e20, 0x1904ba0, 0xc42092f920)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:52 +0x66
go/ast.Walk(0x1901be0, 0xc43df39e20, 0x19042e0, 0xc4209e1480)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:136 +0x1041
go/ast.walkExprList(0x1901be0, 0xc43df39e20, 0xc420a6fcf0, 0x1, 0x1)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:26 +0x81
go/ast.Walk(0x1901be0, 0xc43df39e20, 0x19040e0, 0xc4209e14c0)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:207 +0x2122
go/ast.walkStmtList(0x1901be0, 0xc43df39e20, 0xc420eb5300, 0x8, 0x8)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:32 +0x81
go/ast.Walk(0x1901be0, 0xc43df39e20, 0x1904260, 0xc420975530)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:224 +0x1b7a
go/ast.Walk(0x1901be0, 0xc43df39e20, 0x19046e0, 0xc420975560)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:344 +0xd83
go/ast.walkDeclList(0x1901be0, 0xc43df39e20, 0xc420cf0a00, 0x9, 0x10)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:38 +0x81
go/ast.Walk(0x1901be0, 0xc43df39e20, 0x1904660, 0xc420eb5380)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:353 +0x2672
go/ast.Inspect(0x1904660, 0xc420eb5380, 0xc43df39e20)
/usr/local/Cellar/go/1.9.3/libexec/src/go/ast/walk.go:385 +0x4b
github.com/object88/langd.(*Workspace).LocateDeclaration(0xc420170450, 0xc440c8ea50, 0xc42092f900, 0x0, 0x0)
/Users/bropa18/work/src/github.com/object88/langd/workspace.go:160 +0x277
github.com/object88/langd/requests.(*definitionHandler).work(0xc42a85ed40, 0x756ea1054a2a01, 0xc43aad67c0)
/Users/bropa18/work/src/github.com/object88/langd/requests/definition.go:72 +0x7c
github.com/object88/langd/requests.(*Handler).finishProcessing(0xc42008f860, 0x190d140, 0xc42a85ed40)
/Users/bropa18/work/src/github.com/object88/langd/requests/handler.go:197 +0x35
created by github.com/object88/langd/requests.(*Handler).startProcessing
/Users/bropa18/work/src/github.com/object88/langd/requests/handler.go:193 +0x109
Problem is suspected to be that once the project is opened, we handle the didOpen
request, which will cause the package to reload. We immediately then run definition
, but the reload hasn't finished, so we get a nil package pointer. This is bad, m'key?
The request implementations do not currently take advantage of the locks that the workspace provides, which can allow runtime errors.