Godot: Remote debugger fails on MacOS with status code 2

[zanew]

Operating system or device - Godot version:
v2.1.3 stable official 15" MBP retina gen 2 OS X El Cap 10.11.6

Issue description:

Ran a scene. Expected the scene to build and run. Didn't. Got error in the debugger with text Remote debugger: connection failed with status code 2" retrying in 1 sec.

Steps to reproduce:
Follow steps of hello world tutorial.

Link to minimal example project:

[volzhs]

what value do you have at Settings > Editor Settings > Network > Debug Host?

[zanew]

6c6f:3000:0:0:0:0:0:0

[tooldoctor]

I was doing a tutorial from http://codetuto.com/tag/godot/ and it was working fine until I added the first script, then the same problem occurred on my Retina Mac Book Pro 15 running OSX El Capitan 10.11.16.

I was able to fix it by editing the engine.cfg file and added:

[debug]

debug_port=3000

After doing that, I was able to see the debug_port property in the Project Settings UI for section Debug. (screenshot was edited to show only relevant information)

I had the same problem on a Mac Book Pro 13 running Sierra. Interesting, I saw the debug_port property in the settings and was able to change it on the UI directly. Perhaps it's a different version of Godot that has the fix mentioned above. The About screen says it's the same Godot Engine v2.1.3.stable.official

[akien-mga]

@Faless, any idea? I think we might have messed things up with a cherry-pick of your master edits, looks like debug/debug_port is not being defined as it's expected to be.

[Zireael07]

I'll chime in to say it's not specific to MacOS, see #8744 (and the fact that debugger errors can prevent you from running a project AT ALL is a major annoyance when it does, intermittently, happen)

[Faless]

This seems to only apply to 2.1 branch can someone confirm that? @akien-mga @Zireael07 @zanew

I think we should just get rid of the debug_port as a project variable and use it as an editor variable like we do for the debug_host. Seeing it there is too misleading. They can be passed as command line options anyway for builds without the editor.

I'll have some time to investigate the issue further next week, I've been quite busy with work lately.

[janparkio]

Actually @akien-mga, @Faless this bug is not present in the beta v2.1.4 under the same specifications mentioned in my issue #9635

Hope this alleviates some of that heavy lifting.
Saluti,

[Faless]

@zanew @Zireael07 can somebody with a Mac check if this issue happens on the current 2.1 branch?

[Zireael07]

@Faless I don't have a Mac, I'm on Windows, and the issue seems to have disappeared for me (the debugger connects nicely)

[Faless]

I don't have a Mac, I'm on Windows

Right, my bad.

and the issue seems to have disappeared for me

@Zireael07 can you close #8744 then?

[Faless]

@bojidar-bg since you are in this discussion, I think this can be closed alongside #9635 which was reported as fixed by original author. This appears to be the same problem. Current 2.1 branch should be unaffected, like 2.1.4 beta.

[janparkio]

Yes @Faless, the beta does input the Debugger and prints correctly.

[vnen]

Closing as fixed then.

[retendo]

Mac (Sierra 10.12.6) user here. I still get the error in stable version 2.1.4

For me it is easily reproducible by just

• creating a new project
• adding a root node2d
• save scene and set it as main scene
• run
  -> Error: Remote debugger: connection failed with status code 2

Do you know any workarounds?
It seems that I cannot start using Godot like this, which I would really like to.

EDIT:
It seems, this is not a deal breaker for now. The game window appeared at the outer right edge of one of my displays, where I didn't see it. So that means it can still run the game.
The error message persists though.

I inspected the code to make some sense of it. This part from core/script_debugger_remote.cpp should be responsible:

if (tcp_client->get_status() == StreamPeerTCP::STATUS_CONNECTED) {
            break;
        } else {

            OS::get_singleton()->delay_usec(1000000);
            print_line("Remote Debugger: Connection failed with status: " + String::num(tcp_client->get_status()) + "'', retrying in 1 sec.");
        };

This is a bit weird as per documentation:
STATUS_CONNECTED = 2 — A status representing a StreamPeerTCP that is connected to a host.

And I get Connection failed with status: 2

[Faless]

@retendo can you check what is the value you see in Settings -> Editor Settings -> Network -> Debug Host, and Settings -> Editor Settings -> Network -> Debug Port and report them here?

This is a bit weird as per documentation:
STATUS_CONNECTED = 2 — A status representing a StreamPeerTCP that is connected to a host.

And I get Connection failed with status: 2

Weird indeed... Do you get status: 2 three times or only the last one? What are the previous messages?
It might be that it connected (status: 2) only during the delay of the last try. In that case we might just raise the number of tries.

[chenzhekl]

We still observed the message Connection failed with status: 2 on 2.1.4 on macOS. The debug port was 6096, and the message just appeared once. After that, the debugger seemed to work fine...

[aragalie]

Guys, i'm still getting this issue (2.1.4) on macOS (HighSierra 10.13.2). It's the first time i'm using Godot btw......not sure if it matters now anyways with 3.0 coming out in a few days, but just wanted to let you know this is still an issue.

[Faless]

@aragalie the proper fix for this issue was merged on September 19th, Godot 2.1.4 was released in August. Either compile latest 2.1 branch from source or set Settings -> Editor Settings -> Network -> Debug Host to 127.0.0.1

[clayheaton]

@Faless I just downloaded 3.0.2.stable.official on High Sierra and I get this same error while trying to follow the official Godot tutorial. Changing the debug host and/or port do not alleviate the problem. The window does not appear anywhere for me.

** Debug Process Started **
Remote Debugger: Connection failed with status: '2', retrying in 1 msec.
OpenGL ES 3.0 Renderer: AMD Radeon Pro 460 OpenGL Engine
** Debug Process Stopped **

@vnen I'm not sure this is fixed for 3.0.2 for MacOS

[samgreen]

I think the issue might be here:

https://github.com/godotengine/godot/blob/18c28c159d12c9d3227c2199998b271f7c5e5998/main/main.cpp#L641

Can you post your editor log when you play a scene? I show something like this on Windows 10:

Running: Godot_v3.0.2-stable_win64.exe --path Documents/Godot/hello_world --remote-debug 127.0.0.1:6007 --allow_focus_steal_pid 13796 --position 768,240
running cmdline: "Godot_v3.0.2-stable_win64.exe" "--path" Documents/Godot/hello_world" "--remote-debug" "127.0.0.1:6007" "--allow_focus_steal_pid" "13796" "--position" "768,240"

Can test OS X tomorrow.

[clayheaton]

@samgreen The only thing that appears in the editor Output is what I included in the post above. Not sure if it matters but my computer is connected to an external monitor.

[jtuttle]

@samgreen I'm also experiencing this problem with 3.0.3 on OSX 10.12.5. My output window shows the same as @clayheaton 's:

** Debug Process Started **
Remote Debugger: Connection failed with status: '2', retrying in 1 msec.
OpenGL ES 3.0 Renderer: Intel Iris Pro OpenGL Engine
** Debug Process Stopped **

[clayheaton]

@Faless @vnen This issue needs to be reopened.

[Faless]

I'm also experiencing this problem with 3.0.3

Was it also present in 3.0.2?

[clayheaton]

Yes

On Jun 21, 2018, at 8:07 AM, Fabio Alessandrelli [e-mail] wrote:

I'm also experiencing this problem with 3.0.3

Was it also present in 3.0.2?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Faless]

Yes

Can you try this branch and see if the problem is present there too? https://github.com/Faless/godot/tree/ipv6_detect

[clayheaton]

@Faless

A few things -- I compiled from the branch you linked but I'm getting a permissions-related crash when I try to create a new project. The system never asks me if the app can have permission to run. How do I get around that?

Back to the topic of this issue:

At home, when I've encountered this problem, I have 1 external monitor. The arrangement is the MBP laptop on the left and the external monitor on the right.

Right now, I'm at work, where i have 2 external monitors chained to a MBP. The arrangement is:

When I download 3.0.3 and run a simple test, with Godot in the center monitor in the image above (create a new project, create & save a scene, click Play Scene), the play window appears at the bottom left corner, mostly off-screen, on the right-most monitor. Looks like this:

Is it possible that Godot is trying to open the play scene on a monitor to the right that doesn't exist? (which would make sense for why it works on my setup at my office where I have an additional monitor to the right).

[clayheaton]

Followup... with Default Editor settings under Run, the play window appears here when it should appear in the center:

If I change the setting to Top Left

then it appears almost in the center of the screen:

For reference, I'm using 3 displays. One of them is high DPI and the other two are not.

Edit: @Faless Just to provide confirmation... If I change the scaling on the high-DPI screen, it changes where the play window appears on the non-high-DPI screen where Godot is running when I press Play. So, I'm guessing that the original reported issue of the screen not appearing at all related to the same problem.

To reproduce.
1) Get a laptop with a high-DPI screen (I'm using a Mac) attached to an external monitor that is not high-DPI. Have the external monitor arranged to the right of the laptop screen.
2) Run Godot on the external monitor & create a scene and click play.
3) Change the scaling on the high-DPI laptop screen and then press play in Godot again. If the window appeared at all the first time, it now will appear in a different location. If it did not appear, I strongly suspect that's because the resolution of the high-DPI screen is being used to determine the location on the external monitor, causing the window to draw off screen, resulting in the Connection Failed and/or rendering error.

[AdamantGaming]

@Faless I am also experiencing this problem on 3.0.6 from a MacBook Pro. No external displays connected currently, but I used to use 3 monitors. I tried changing the debug_host, debug_port to no avail. I also tried enabling and disabling the "Deploy With Remote Debugger" option, and every combination of options listed, and all had the same result:

* Debug Process Started *
Remote Debugger: Connection failed with status: '2', retrying in 1 msec.
OpenGL ES 3.0 Renderer: AMD Radeon Pro 560 OpenGL Engine
* Debug Process Stopped *

Any troubleshooting I can do to help figure this out? I am planning to start getting heavily invested in this version of Godot, and myself and my team almost exclusively work from Macbook Pros.

[reduz]

It seems odd that the debugger connection fails, maybe a way to check if the port is in use? though if this is the case, I think Godot tries to open another port..

[Faless]

@AdamantGaming as mentioned in above comments, your issue (and this GH issue in general) is likely no longer related to any network code.
As the log says, the debugger fails, retry, and then succeed when retrying after 1 ms (and in fact, you get the first line of the log: OpenGL ES 3.0 Renderer: AMD Radeon Pro 560 OpenGL Engine).
Your problem is somewhere else (e.g.check out #13017 ).
I'm thinking about remove that debug line Remote Debugger: Connection failed with status: '2', retrying in 1 msec. as it seems no one understands it, and is always misinterpreted as a network error (like in this case, where it's not).

[AdamantGaming]

@Faless - Yeah I completely misunderstood that. My bad.

Rather than removing the initial message, maybe a more clearly defined success message would be beneficial? Such as a line between the connection failed message, and the first line of the log that says "Retry Successful - now displaying debug log."?

[Faless]

Such as a line between the connection failed message, and the first line of the log that says "Retry Successful - now displaying debug log."?

Yes, good idea! :+1: