Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Couldn't connect on 127.0.0.1:6000 with VSCode 1.82.0 #602

Closed
DigiEggz opened this issue Sep 7, 2023 · 25 comments
Closed

Couldn't connect on 127.0.0.1:6000 with VSCode 1.82.0 #602

DigiEggz opened this issue Sep 7, 2023 · 25 comments

Comments

@DigiEggz
Copy link

DigiEggz commented Sep 7, 2023

VSCode updated itself to 1.82.0 and I immediately started getting the error Fatal error: exception Failure("Couldn't connect on 127.0.0.1:6000") whenever I try to compile to any target.

Below are the build details of my current version of VSCode:

Version: 1.82.0 (Universal)
Commit: 8b617bd08fd9e3fc94d14adb8d358b56e3f72314
Date: 2023-09-06T22:09:41.364Z
Electron: 25.8.0
ElectronBuildId: 23503258
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Darwin x64 22.4.0
@Syopic
Copy link

Syopic commented Sep 8, 2023

Yes, downgrading to 1.81.1 solves the problem

@giuppe
Copy link

giuppe commented Sep 8, 2023

A workaround is to explicitly launch
haxe -v --wait 6000
in a vscode terminal.

@Soup-Wizard
Copy link

Seriously, THANK YOU ALL. I just started trying Haxe/Heaps last night and couldn't even get the Hello World file for heaps to compile. Reverting VS Code versions worked.

@kLabz
Copy link
Contributor

kLabz commented Sep 11, 2023

Anyone reproduces this issue on linux? (or windows btw, could be a mac only issue somehow)

@kisetil
Copy link

kisetil commented Sep 11, 2023

Hi, I have the same problem on Windows, a few days ago before the VS update everything worked correctly. Regards

@israboy-tech
Copy link

israboy-tech commented Sep 11, 2023

Thanks everyone for identifying the root source of the issue, I spent all weekend trying to solve this!

A workaround is to explicitly launch haxe -v --wait 6000 in a vscode terminal.
Doing this will let you compile but I couldn't debug (or even run the application).

Anyone reproduces this issue on linux? (or windows btw, could be a mac only issue somehow)
I can confirm this is something happening on Windows 10 too.

@djaonline
Copy link

djaonline commented Sep 11, 2023

I've been having the same issue on my linux distro since 1.78 version of vscode. #589

@datee
Copy link

datee commented Sep 12, 2023

I had the same issue too! Had to downgrade VSCode to 1.81 on Windows ... is a fix possible?

@RblSb
Copy link
Member

RblSb commented Sep 12, 2023

We added better connection error message to nightly, so someone can test it and write what exactly unix error this is (maybe @kLabz can rebuild this commit to make it available on build.haxe.org)
HaxeFoundation/haxe@44c9abd

@AlexHaxe
Copy link
Member

after some testing on a Windows machine I found out what causes it and how to reproduce it:
on systems where localhost resolves to ::1 vshaxe will open port 6000 on localhost (== ::1) while haxe --connect 6000 will try to connect to 127.0.0.1 which obviously fails (with No connection could be made because the target machine actively refuxed it.).

so if your hosts file contains the line ::1 localhost then you will likely run into that problem (that's also how you provoke it).

@RblSb
Copy link
Member

RblSb commented Sep 12, 2023

Can be related to vscode change where v4 ips are not sorted first anymore?
microsoft/vscode#192545

@AlexHaxe
Copy link
Member

could be yes.

I guess the solution would be to explicitly set hostname to localhost when running tasks via compilation server (so tasks and Haxe server use the same name).

@RblSb
Copy link
Member

RblSb commented Sep 12, 2023

Hm, why not replace "localhost" with "127.0.0.1" instead, in vshaxe and lsp?

@AlexHaxe
Copy link
Member

Haxe compiler defaults to 127.0.0.1 when no host is given, so maybe we just change haxe-languageserver to a fixed ip address instead of localhost.

@kLabz
Copy link
Contributor

kLabz commented Sep 12, 2023

I'd think using localhost everywhere is a better idea.

It is also important to note you cannot always use 127.0.0.1 for loopback. IPv6 only systems do not respond to such requests since their localhost is linked to the address : :1.

Another significant difference between localhost and 127.0.0.1 is how the request is sent. The request does not go through the network card when pinging the loopback address with the localhost. On the other hand, running 127.0.0.1 does pass through the network card, which may be affected by firewall settings and configurations.

Plus other things like people actually wanting to use some other IP for localhost, etc

@AlexHaxe
Copy link
Member

well, localhost somehow doesn't seem to work. not even on console.

on Windows I can telnet ::1 6000 and get Haxe output, but haxe --connect localhost:6000 doesn't seem to connect (and obviously haxe --connect [::1]:6000 doesn't work, because Haxe uses split on : to separate host and port).

on Linux localhost doesn't work even though it resolves to 127.0.0.1. using haxe --connect 127.0.0.1:6000 works however (as does --connect 6000). telnet localhost 6000 successfully connects.

comparing haxe --connect localhost:6000 with haxe --connect 6000 and haxe --connect 127.0.0.1:6000 on Windows shows that localhost produces

Fatal error: exception Failure("Couldn't connect on localhost:6000")

whereas the other two show

Fatal error: exception Failure("Couldn't connect on 127.0.0.1:6000 (No connection could be made because the target machine actively refused it.\r\n)")

tested with haxe_20230908125023_536c388_bin.zip from build artifacts (win64 binaries)

not sure what to make of it.

looking at Haxe source code, I believe it only supports IPv4 sockets for --connect so anything IPv6 cannot work without modifying Haxe first. basically ruling out anything using a hostname for connections, because a hostname can have an A and an AAAA record in DNS and Haxe wouldn't know which one to choose (and would have to try both IPv6 and IPv4 connections).

@Simn
Copy link
Member

Simn commented Sep 13, 2023

I'm happy to add IPv6 support to Haxe for this, but that doesn't really help us with the current problem because existing versions have to function anyway...

@kLabz
Copy link
Contributor

kLabz commented Sep 13, 2023

I'm checking for ipv6 support in Haxe atm and it seems pretty straightforward
Not sure if there's a nice fix on vshaxe/haxe lsp side only that would cover all these :/

@kLabz
Copy link
Contributor

kLabz commented Sep 13, 2023

@AlexHaxe Does haxe --wait 127.0.0.1:6000 + haxe --connect 127.0.0.1:6000 work on such a windows machine using ::1 as localhost?

If so, proposed plan:

  • Add some kind of "haxe server host" config to vshaxe + haxe lsp, with 127.0.0.1 as default
  • Use it explicitly for --wait and --connect
  • Update Haxe host+port parsing + socket opening to support ipv6 too for future proofing

@datee
Copy link

datee commented Sep 13, 2023

this does not work for me (windows 10/11)

haxe --wait 127.0.0.1:6000
Fatal error: exception Failure("Couldn't wait on 127.0.0.1:6000")

in my hosts file:

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost

Meaning its commented out, right...?

@AlexHaxe
Copy link
Member

haxe --wait 127.0.0.1:6000
Fatal error: exception Failure("Couldn't wait on 127.0.0.1:6000")

you have some process already occupying port 6000. you can only have one combination of host and port open on a single system.

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost

try ping localhost, it's probably pinging ::1.

@AlexHaxe
Copy link
Member

@kLabz seems to be working. I'm going to do some more testing and then we can aim for a new version.

AlexHaxe added a commit to AlexHaxe/vshaxe that referenced this issue Sep 13, 2023
@AlexHaxe
Copy link
Member

vshaxe version 2.30.0 was just released. you should now be able to upgrade to VSCode 1.82.x

@hoseyjoe
Copy link

vscode hashlink debugger stopped working around same time for me. Is this potentially the same fix?

@kLabz
Copy link
Contributor

kLabz commented Sep 15, 2023

Seems likely indeed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests