debug: opaque error message when "go.toolsEnvVars" are incompatible with host machine

[ramya-rao-a]

From microsoft/vscode-go#2696 by @firelizzard18:

Steps to Reproduce:

1. Open a Go project that has launch configurations
2. Open settings and edit "go.toolsEnvVars" and add "GOOS": "windows" (or "GOOS": "linux" if your OS is Windows)
3. Attempt to launch a debug session

The error:

could not launch process: stub exited while waiting for connection: exit status 0
Process exiting with code: 1

The issue is that it is not at all obvious why this is failing. Ideally, vscode-go would know that the debugger failed because of GOOS/GOARCH. But I don't know how it would do that, without dlv providing a more meaningful error. Failing that, a warning would be nice. "By the way, we see you've changed GOOS/GOARCH such that the debugger will likely fail."

[ramya-rao-a]

Proposed solution after the discussion in microsoft/vscode-go#2696:

Show a warning before even starting delve in such cases. We can have this warning include 2 buttons: Ignore GOOS and GOARCH from settings and Continue.

This can be done in the goDebugConfiguration.ts file as suggested in the Code Pointers in microsoft/vscode-go#2696 (comment)

[polinasok]

The most recent message looks like so (still not immediately obvious what the issue is):

@aarzilli
In which cases are cross-platform GOOS/GOARCH useful? I think core mode is one. Instead of implementing a user prompt, perhaps it would be cleaner to ignore these for certain modes?

[aarzilli]

I think ignoring them would lead users into thinking they are accomplishing something by setting GOOS/GOARCH. I think we should do what the user asks and fail, so that the user can better form a model of what delve does.

In which cases are cross-platform GOOS/GOARCH useful? I think core mode is one

In any case where we don't call the compiler GOOS/GOARCH aren't used and therefore do not interfere, including core mode. I wouldn't call that "useful"

[polinasok]

I think ignoring them would lead users into thinking they are accomplishing something by setting GOOS/GOARCH. I think we should do what the user asks and fail, so that the user can better form a model of what delve does.

This issue was filed because a user did cross-platform development and accidentally left the settings intended for gopls in the global configuration and forgot about them. Then later when they tried to launch-debug, the settings were applied and they got an error, but the message said nothing about the os/arch mismatch, so they were not sure what was going on and asked that we improve the error message.

The conclusion a while back was that vscode-go extension could compare GOOS/GOARCH to that of the machine and if they did not match, offer warning and a prompt to ignore them or continue. But if these settings are never useful in any or all cases, then why do the check and offer a choice at all? That's what I am trying to determine: when are they useful? We don't have to silently ignore them when they are not. We can always print a warning and update documentation.

In any case where we don't call the compiler GOOS/GOARCH aren't used and therefore do not interfere, including core mode. I wouldn't call that "useful"

Ah, I see. I just assumed they are used somehow because I remember reading that you can debug core file from one platform while running dlv on another.

[aarzilli]

All of this is also true for go run:

$ GOARCH=arm64 go run hello.go
fork/exec /dev/shm/go-build2434359517/b001/exe/test: exec format error

[firelizzard18]

But if these settings are never useful in any or all cases, then why do the check and offer a choice at all? That's what I am trying to determine: when are they useful? We don't have to silently ignore them when they are not. We can always print a warning and update documentation.

In my opinion showing an error is a better user experience than silently ignoring the setting. If the user sees a prompt, "Hey you tried to debug using an incompatible GOOS/GOARCH," it's pretty obvious what happened.

I can easily imagine a scenario where I'm running on Linux, working on stuff_windows.go, I set GOOS to make sure the Windows-specific code compiles, then decide I need to test it and try to debug. Obviously that wouldn't work, but sometimes I forget pesky details like "you can't run Windows code on Linux" when I'm in the zone. And I can easily imagine myself spending an extremely frustrating 10 minutes trying to figure out why the code I'm working on isn't being debugged before I remember "DOH! 🤦 I can't debug Windows code on Linux!"

There's a great book on human-interface usability called Don't Make Me Think. When designing UX, the less the user has to think the better their experience will be. If an error message pops up telling me "Hey you can't do that" I don't have to think. That's a much better UX than spending time trying to figure out why code isn't running.

[firelizzard18]

All of this is also true for go run:

$ GOARCH=arm64 go run hello.go
fork/exec /dev/shm/go-build2434359517/b001/exe/test: exec format error

It would be nice if go run had a better error message, but at least when I see "exec format error" I know exactly what's wrong.

[polinasok]

All of this is also true for go run:

$ GOARCH=arm64 go run hello.go
fork/exec /dev/shm/go-build2434359517/b001/exe/test: exec format error

I think a big difference between this instance of go run or even

$ GOOS=windows dlv debug  _fixtures/increment.go 
could not launch process: not an executable file

is that when you see a failure, you know exactly what to inspect for issues - your command-line. When it happens in vscode, the problem is buried deep in settings. You get a standard message to check launch.json, but settings.json. And even then, which of the many fields there is the likely offender? It's not clear. I think it would be nice to improve the error message.

I was assuming it was coming from some underlying dependencies, but I see now that it is defined in delve itself, so this seems like an easy fix.

[aarzilli]

is that when you see a failure, you know exactly what to inspect for issues - your command-line. When it happens in vscode, the problem is buried deep in settings

Not really, you could have the environment variable set somewhere else.

[yiGmMk]

The most recent message looks like so (still not immediately obvious what the issue is): @aarzilli In which cases are cross-platform GOOS/GOARCH useful? I think core mode is one. Instead of implementing a user prompt, perhaps it would be cleaner to ignore these for certain modes?

Helps a lot, Previously I change GOOS=windwos for test in Linux machine and then when debug I got such error "dap Failed to launch: could not launch process: not an executable file" ,everything runs ok,the build out also appears and immediate deleted.with GOOS set correctly,debug works again

if this can be detectd whit more detail error tips will be better,just point out some possible wrong config