Directory named 'go' in path results in EACCES error

[DonMcNamara]

In getBinPathFromEnvVar the code returns the first path that exists, regardless of permission. If that path is a directory named go and not an executable, the code will attempt to execute go version on the directory. This results in: error spawn eacces

Line of code in question: https://github.com/Microsoft/vscode-go/blob/master/src/goPath.ts#L24

Fix: I'm not too familiar with node, but checking the docs, I think this can be fixed by using the fs.accessSync method.

Workaround: Re-order your path, so the go executable is found before the directory.

[ramya-rao-a]

fs.accessSync would still not help in differentiating file vs directory. Will use fs.statSync instead Here is a nice comparision: https://www.gregjs.com/javascript/2016/checking-whether-a-file-directory-exists-without-using-fs-exists/

[DonMcNamara]

Thank you!

[ramya-rao-a]

The latest update (0.6.48) has the fix. Happy Coding!

[jeffprestes]

Sorry, I am still facing same issue to debug my application with Delve I followed these steps: https://fresh-air.aerobatic.io/post/debug-golang/ but I am using a MAC I gave +x permission to vscode directories and to my application directory and same issue. Could you help me out to check where I should set the correct permission?

[ramya-rao-a]

@jeffmcaffer Can you share the complete error message you are seeing? Also open the console (Developer: Toggle Developer Tools) and share any errors and call stack from there.

[jeffprestes]

@ramya-rao-a for sure. Failed to continue: "Error: spawn EACCES"

messageService.ts:126 Failed to continue: "Error: spawn EACCES": Error: Failed to continue: "Error: spawn EACCES"
    at Object.g [as create] (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:30:20765)
    at file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:128:7799
    at Object.v [as _notify] (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:13263)
    at Object.enter (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:16768)
    at _run (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:18089)
    at _chainedError (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:17448)
    at n (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:15271)
    at then (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:18898)
    at Object.enter (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:15340)
    at _run (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:18089)
    at _setCompleteValue (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:17783)e.doShow @ messageService.ts:126e.show @ messageService.ts:105(anonymous function) @ compositePart.ts:284r @ eventEmitter.ts:314e._emitToSpecificTypeListeners @ eventEmitter.ts:182e._emitEvents @ eventEmitter.ts:201e.emit @ eventEmitter.ts:216(anonymous function) @ actions.ts:231v @ winjs.base.raw.js:1209enter @ winjs.base.raw.js:901_run @ winjs.base.raw.js:1068_chainedError @ winjs.base.raw.js:1031n @ winjs.base.raw.js:736then @ winjs.base.raw.js:1436enter @ winjs.base.raw.js:747_run @ winjs.base.raw.js:1068_setCompleteValue @ winjs.base.raw.js:1052v @ winjs.base.raw.js:1209enter @ winjs.base.raw.js:901_run @ winjs.base.raw.js:1068_chainedError @ winjs.base.raw.js:1031n @ winjs.base.raw.js:736then @ winjs.base.raw.js:1436enter @ winjs.base.raw.js:747_run @ winjs.base.raw.js:1068_setCompleteValue @ winjs.base.raw.js:1052v @ winjs.base.raw.js:1209enter @ winjs.base.raw.js:901_run @ winjs.base.raw.js:1068_error @ winjs.base.raw.js:1041(anonymous function) @ v8Protocol.ts:53e.dispatch @ v8Protocol.ts:136e.handleData @ v8Protocol.ts:104(anonymous function) @ v8Protocol.ts:41emitOne @ events.js:96emit @ events.js:188readableAddChunk @ _stream_readable.js:176Readable.push @ _stream_readable.js:134onread @ net.js:543
index.js:22 [uncaught exception]: Error: Unable to display threads: "Error: spawn EACCES"onError @ index.js:22(anonymous function) @ index.js:91emitOne @ events.js:96emit @ events.js:188window.onerror @ init.js:120i.globals.onerror @ errorTelemetry.ts:64
index.js:25 Error: Unable to display threads: "Error: spawn EACCES"
    at rawDebugSession.ts:181
    at Object.v [as _notify] (winjs.base.raw.js:1209)
    at Object.enter (winjs.base.raw.js:901)
    at _run (winjs.base.raw.js:1068)
    at _error (winjs.base.raw.js:1041)
    at v8Protocol.ts:53
    at _.e.dispatch (v8Protocol.ts:136)
    at _.e.handleData (v8Protocol.ts:104)
    at Socket.<anonymous> (v8Protocol.ts:41)
    at emitOne (events.js:96)
    at Socket.emit (events.js:188)onError @ index.js:25(anonymous function) @ index.js:91emitOne @ events.js:96emit @ events.js:188window.onerror @ init.js:120i.globals.onerror @ errorTelemetry.ts:64
rawDebugSession.ts:181 Uncaught Error: Unable to display threads: "Error: spawn EACCES"(anonymous function) @ rawDebugSession.ts:181v @ winjs.base.raw.js:1209enter @ winjs.base.raw.js:901_run @ winjs.base.raw.js:1068_error @ winjs.base.raw.js:1041(anonymous function) @ v8Protocol.ts:53e.dispatch @ v8Protocol.ts:136e.handleData @ v8Protocol.ts:104(anonymous function) @ v8Protocol.ts:41emitOne @ events.js:96emit @ events.js:188readableAddChunk @ _stream_readable.js:176Readable.push @ _stream_readable.js:134onread @ net.js:543
shell.ts:541 Unable to display threads: "Error: spawn EACCES": Error: Unable to display threads: "Error: spawn EACCES"
    at file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:90:21136
    at Object.v [as _notify] (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:13263)
    at Object.enter (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:16768)
    at _run (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:18089)
    at _error (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:32:17606)
    at file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:85:1178
    at _.e.dispatch (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:85:2523)
    at _.e.handleData (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:85:2035)
    at Socket.<anonymous> (file:////Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.js:85:1038)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)e.onUnexpectedError @ shell.ts:541(anonymous function) @ shell.ts:457e.onUnexpectedError @ errors.ts:68o @ errors.ts:88(anonymous function) @ winjs.base.js:43(anonymous function) @ winjs.base.js:38
winjs.base.js:45 WARNING: Promise with no error callback:185
winjs.base.js:46 Object {exception: null, error: Error: Unable to display threads: "Error: spawn EACCES"
    at file:////Applications/Visual Studio C…, promise: n.C…s.d…e.cancel, handler: undefined, id: 185…}

[ramya-rao-a]

Thanks @jeffprestes, and can you confirm that the rest of the Go extension features work for you? Like Hover Info, Goto Definition, Find all references, Rename, Building, Linting, Formatting?

And is dlv working from the command line for you? This is to ensure that the dlv set up was correctly done.

cc @roblourens for thoughts on the callstack related to debugging

[jeffprestes]

Except for debug, coding Go using vscode in my machine is great! It's an amazing tool. We just need to fix this to become perfect! dlv in command line is also running OK.

[ramya-rao-a]

The "Unable to display threads" is coming from https://github.com/Microsoft/vscode-go/blob/master/src/debugAdapter/goDebug.ts#L440 when try to get list of goroutines from delve.

@roblourens Is threadsRequest() one of the first things expected to run in the debug adapter?

@jeffprestes

Delve is failing to return the list of goroutines and giving the error EACCES error.

Are you able to execute the step and goroutines commands when running dlv debug in the command line?

Have you set go.goroot in your settings to anything that is different than the default by any chance?

[roblourens]

threadsRequest is sent only after hitting a breakpoint, which would imply that delve worked well enough to tell us that it hit a breakpoint. Not sure why that would happen.

[roblourens]

Actually if you have stopOnEntry enabled, it would be sent very early, do you?

[jeffprestes]

Hi @ramya-rao-a ,

Have you set go.goroot in your settings to anything that is different than the default by any chance? No, I haven't. This is my config:

{
    "version": "0.2.0",
    "configurations": [        
        {
            "name": "Launch",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "remotePath": "",
            "port": 2345,
            "host": "127.0.0.1",
            "program": "${workspaceRoot}",
            "env": {},
            "args": [],
            "showLog": true
        }
    ]
}

I could be wrong but EACCES error is related to Javascript. But I can be wrong.

About Delve in my machine, at command line it is running sweet. See the logs below.

~/myproject (master %)$ dlv debug
Type 'help' for list of commands.
(dlv) break RunningPort
Breakpoint 1 set at 0x8217d for /lib/utils.RunningPort ./lib/utils/whereami.go:12
(dlv) next
Command failed: no G executing on thread 0
(dlv) continue
> /lib/utils.RunningPort() ./lib/utils/whereami.go:12 (hits goroutine(1):1 total:1)
     7:
     8: /*
     9: RunningPort returns the HTTP Port where the application is listening requests
    10: */
    11: func RunningPort() int {
=>  12:     if i, err := strconv.Atoi(os.Getenv("PORT")); err == nil {
    13:         return i
    14:     }
    15:     return 8765
    16: }
    17:
(dlv) next
> /lib/utils.RunningPort() ./lib/utils/whereami.go:15
    10: */
    11: func RunningPort() int {
    12:     if i, err := strconv.Atoi(os.Getenv("PORT")); err == nil {
    13:         return i
    14:     }
=>  15:     return 8765
    16: }
    17:
    18: /*
    19: AmILocal returns true if it's nunning on localhost at 8080 port or false in different port 
    20: */
(dlv) goroutines
[5 goroutines]
* Goroutine 1 - User: ./lib/utils/whereami.go:15/lib/utils.RunningPort (0x821bd)
  Goroutine 2 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x2c59a)
  Goroutine 3 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x2c59a)
  Goroutine 4 - User: /usr/local/go/src/runtime/proc.go:260 runtime.gopark (0x2c59a)
  Goroutine 17 - User: /usr/local/go/src/runtime/asm_amd64.s:2087 runtime.goexit (0x591c1)

Oh! Could I give a suggestion? In order to help you and @roblourens to reproduce the error, I'd suggest you to get a Mac, setup the Go Dev development environment and try this: http://nanxiao.me/en/a-brief-intro-of-delve/ and this https://blog.gopheracademy.com/advent-2015/debugging-with-delve/ tutorials. If you were able to run the debug process in your machines within vscode, please let me know and share a print screen. Then I would start to consider that is something wrong in my machine not in the vscode. I believe this is help you to speed up the fix processing ;)

And again, I appreciate your efforts to fix this and give to Go Dev community this important tool. I will be waiting for your news. Thanks a lot!

[roblourens]

Why did the 'next' request fail? That seems relevant. Also, what version of MacOS do you have? I haven't used it on a Mac in awhile since Delve was broken on 10.12.x, but it looks like it's usable now, so I can try that out this week: https://github.com/aaronhackney/delve_on_mac

[jeffprestes]

Rob,

Please, read what I have written correctly, I didn't say 'next' is not working. Delve is working fine. Again, Delve is working fine. Check the logs out. I can debug my Go application without VSCode with no problem. What I am trying to do is helping you to create a better IDE but if you don't care about Go Developers that use Mac, OK, I won't spend my time trying to convince you.

• Jeff Prestes

Em 23 de jan de 2017 3:12 PM, "Rob Lourens" notifications@github.com escreveu:

Why did the 'next' request fail? That seems relevant. Also, what version of MacOS do you have? I haven't used it on a Mac in awhile since Delve was broken on 10.12.x, but it looks like it's usable now, so I can try that out this week: https://github.com/aaronhackney/delve_on_mac

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode-go/issues/585#issuecomment-274551404, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgjWQAd_UlM1mFfW7aDWbyFslv7RO_Bks5rVN9egaJpZM4Kkgjq .

[roblourens]

You said it worked but the log says

(dlv) next
Command failed: no G executing on thread 0

which seems wrong, doesn't it? And since the extension does nothing but pass requests on to delve, we want to understand the behavior of Delve here.

I don't doubt that there's an issue, and thanks for helping us understand it.

[ramya-rao-a]

@jeffprestes

I'd suggest you to get a Mac, setup the Go Dev development environment

I am using Mac and have installed delve using brew. I am able to hit breakpoints, step in, step out etc in VS Code using the Go extension

I could be wrong but EACCES error is related to Javascript.

Yes, that is a possibility, in which case my bet is on https://github.com/Microsoft/vscode-go/blob/master/src/debugAdapter/goDebug.ts#L214 where we spawn a new process to start delve.

Error: spawn EACCES while spawning a new process means that there are permission issues in accessing the file (in this case the dlv binary)

The extension is able to find the the dlv binary, otherwise you would have seen the error "Cannot find Delve debugger at... Ensure it is in your "GOPATH/bin" or "PATH"."

Can you think of any reason, why the folder where the dlv binary resides is not accessible to VS Code?

Please try the following, it will help us narrow down the root cause.

• Run go env in the command line. Is the GOPATH you see here and the one you see while runnning Go: Current GOPATH command in VS Code the same?
• Run which dlv in the command line. Is the dlv binary in your GOPATH/bin or PATH ?
• In your workspace/user settings, have you set go.goroot or go.gopath.

The reason I am asking these questions is because GOPATH, PATH and GOROOT (in that order) are used by the Go extension to find dlv.

[jeffprestes]

Hello @ramya-rao-a,

Below are my answers to your questions. I have changed my username for security reasons but it won't be a problem to you understand my dev environment.

Ensure it is in your "GOPATH/bin" or "PATH"." Yep, it is: ~$ which dlv /usr/local/bin/dlv

~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Users/xxxuser/projetos/go/bin ``` 

Run go env in the command line. Is the GOPATH you see here and the one you see while runnning Go: Current GOPATH command in VS Code the same?

Below the results:

~$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/xxxuser/projetos/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sg/cbftgljs34l59llxmnk_mvzr0000gn/T/go-build513615244=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

VSCode: Current GOPATH:/Users/xxxuser/projetos/go

Run which dlv in the command line. Is the dlv binary in your GOPATH/bin or PATH ? Yes, it is as you can see above. And below see the file permissions: lrwxr-xr-x 1 xxxuser admin 30 Jun 25 2016 /usr/local/bin/dlv -> ../Cellar/delve/0.11.0/bin/dlv

In your workspace/user settings, have you set go.goroot or go.gopath.
No, I haven't. They are null as default.

  "go.gopath": null,

  // Specifies the GOROOT to use when no environment variable is set.
  "go.goroot": null,

Thanks again. I appreciate your kindness.

[ramya-rao-a]

The Go extension first looks at GOPATH and then the PATH to find the dlv binary. Is there a file dlv in your $GOPATH/bin? If yes, then that would be used instead of the one that we can clearly see in your /usr/local/bin which is in your PATH

If not, then I am truly stumped :( The only next step I can think of is helping you debug the Go extension to find the issue. Its pretty easy. If you are up for it, I can help you with that.

To set up a dev instance of the Go extension read this. And then to debug the debugger, read this Then in the file goDebug.ts add breakpoints in the callbacks to this.debugProcess.stderr, this.debugProcess.stdout and this.debugProcess.on('close'...

[jeffprestes]

That was it. Accidentally, I had a dlv file at $GOPATH/bin, I removed it and now vscode is debugging like a charm.

Thank you very much @ramya-rao-a for all your attention and kindness. Now I have one more reason to say to Go devs to use vscode instead of vim ;)

[ramya-rao-a]

phew! Glad that worked out. I'll add this as a note in the wiki on debugging we have.

Happy Coding!

[jasonelston]

Maybe this will assist someone if they have the issue. I had the same error popping up as well. Two computers, same version of vscode (1.10.2), same version of vscode-go (0.6.55), one producing the error and one not producing it. I thought it was because the $GOPATH included a symlink directory, even though both had the same path but moving to a hard directory solved it inconsistently (didn't get to the bottom of this). I also eliminated all the possibilities spoken about in this thread. Eventually I solved it by removing all the binaries from $GOPATH/bin and re-installing the tools within vscode -> ctrl-p Go: Install Tools