object88 / langd

A Language Server Protocol implementation in Go for Go
MIT License
7 stars 0 forks source link

Use workspace locks in requests #29

Open object88 opened 6 years ago

object88 commented 6 years ago

The request implementations do not currently take advantage of the locks that the workspace provides, which can allow runtime errors.

object88 commented 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?