Closed
Description
Working with x/tools at commit 487737a1960720c6595131017ff98eef1586fa04, when I build gopls and use it in an emacs session on this file https://go.dev/play/p/_EKzBXvi29C , I get a crash . Full log attached as text file, but the interesting portion of the trace is here:
[stderr] panic: runtime error: slice bounds out of range [238:237]
[stderr]
[stderr] goroutine 704 gp=0xc0015e6000 m=19 mp=0xc000581c08 [running]:
[stderr] panic({0xfb57a0?, 0xc0025840d8?})
[stderr] panic({0xfb57a0?, 0xc0025840d8?})
[jsonrpc] e[13:33:21.074] <-- client/registerCapability[3] {"jsonrpc":"2.0","method":"client/registerCapability","params":{"registrations":[{"id":"workspace/didChangeWatchedFiles-0","method":"workspace/didChangeWatchedFiles","registerOptions":{"watchers":[{"globPattern":"**/*.{mod,work}","kind":7},{"globPattern":"**/*.{go,mod,sum,work}","kind":7}]}}]},"id":3}
[stderr] /w/go.master/src/runtime/panic.go:778 +0x168 fp=0xc00078b8f8 sp=0xc00078b848 pc=0x43e788
[stderr] runtime.goPanicSliceB(0xee, 0xed)
[stderr] /w/go.master/src/runtime/panic.go:154 +0x74 fp=0xc00078b938 sp=0xc00078b8f8 pc=0x43d674
[stderr] golang.org/x/tools/gopls/internal/protocol.(*Mapper).LineCol8Position(0xc000bd63c0, 0xa, 0x0)
[stderr] /w/go1/src/golang.org/x/tools/gopls/internal/protocol/mapper.go:151 +0x1a5 fp=0xc00078b9a0 sp=0xc00078b938 pc=0x7c4b05
[stderr] golang.org/x/tools/gopls/internal/cache.goPackagesErrorDiagnostics.func1({{0xc0006c87a0, 0xa}, {0xc00013c0c0, 0x38}, 0x1}, 0x38?, {0x1300b00, 0xc000563320}, {0x13099c8, 0xc001f99c20})
[stderr] /w/go1/src/golang.org/x/tools/gopls/internal/cache/errors.go:59 +0x145 fp=0xc00078ba20 sp=0xc00078b9a0 pc=0xc6eb65
[stderr] golang.org/x/tools/gopls/internal/cache.goPackagesErrorDiagnostics({0x13099c8, 0xc001f99c20}, {{0xc0006c87a0, 0xa}, {0xc00013c0c0, 0x38}, 0x1}, 0xc000774300, {0x1300b00, 0xc000563320})
[stderr] /w/go1/src/golang.org/x/tools/gopls/internal/cache/errors.go:70 +0xf5 fp=0xc00078bae8 sp=0xc00078ba20 pc=0xc6e6d5
[stderr] golang.org/x/tools/gopls/internal/cache.computeLoadDiagnostics({0x13099c8, 0xc001f99c20}, 0xc000563320, 0xc000774300)
[stderr] /w/go1/src/golang.org/x/tools/gopls/internal/cache/load.go:561 +0x185 fp=0xc00078bc28 sp=0xc00078bae8 pc=0xc797e5
[stderr] golang.org/x/tools/gopls/internal/cache.(*packageHandleBuilder).buildPackageHandle(0xc0000ee660, {0x13099c8, 0xc001f99c20}, 0xc001f98000)
I am guessing that what's at issue here is the tool-generated counter increments.
Thanks.
Metadata
Metadata
Assignees
Labels
Type
Projects
Relationships
Development
No branches or pull requests
Activity
adonovan commentedon May 14, 2024
Thanks for the bug report. I think the problem is that gopls is parsing an error from go list that doesn't have a line or column, which causes it to use zero for both fields, when the correct value is one. Fix pending.
Which package was this file part of? The error message that triggered the fault is a property of the complete package, not just this file.
adonovan commentedon May 14, 2024
Answer: cmd/cover. Never mind.
thanm commentedon May 14, 2024
Thanks for looking into the problem. Admittedly editing the output of cmd/cover is a weird thing to do, but maybe someone else out there might also run into it.
adonovan commentedon May 14, 2024
Can you tell me what exact sequence of steps you used to get the crash? It would be nice to add a test to my CL, but the file by itself doesn't cause a problem, nor do various cmd/cover workflows I've tried. I suspect it's something to do with the file in relation to the other files in your particular workflow, since that's what would cause 'go list' to report an error.
thanm commentedon May 14, 2024
I can see the problem when I copy the file into its own dir and run emacs on it, e.g.
Does this work for you?
adonovan commentedon May 14, 2024
Yep! Thanks. (I swear I already tried that, but I think I must have disabled "auto manage" mode in eglot earlier in the day while debugging a different problem and forgotten to reenable it.)
adonovan commentedon May 14, 2024
Minimal repro:
causes go list error:
Seems like the //line directive is confusing the bounds check.
[-]x/tools/gopls: crash processing Go file generated by cover tool[/-][+]x/tools/gopls: OOB index panic after parsing go list error from file with //line directives[/+]gopherbot commentedon May 14, 2024
Change https://go.dev/cl/585555 mentions this issue:
gopls/internal/cache: use 1 not 0 for missing line/col info
gopls/internal/cache: use 1 not 0 for missing line/col info