Godot error listening on port 6007

A second Godot client on the same PC won’t connect to a websocket server #28749

I can connect a Godot client to a websocket server, but if you’re trying to connect two clients on the same PC, it would not work.

I thought I did something wrong, until someone on Facebook pointed out that this is an issue with Godot.

The text was updated successfully, but these errors were encountered:

Could you give me a little more information to work with?
Did you change the port for each client? or are they trying to access the server using the same port?

Some steps to reproduce the error would be nice. 😄

They’re trying to access the server on the same port.

Here you can test this

Open two clients, the first will connect, the second won’t.

I couldn’t really replicate your error because I don’t really know what kind of server you are using?
There’s also an error in that code because _connection_closed() requires a boolean input:

Have you checked out this demo?
https://github.com/LudiDorici/godot-websocket/tree/master/websocket_chat_demo
I was able to run that demo without any problems with 3 clients connecting to the same server (at the same port).

Maybe the issue is at the side of your server?
It’s a bit difficult from my side because I can’t replicate the error of course. Apologies for that.

The server is a fake server

but even on localhost, I have the same problem

And the code is not mine either, it’s the code that everyone is using

in the websockets folder you’ll find the basic and the advanced example, neither work with multiple clients.

I will run the demo you provided, if the issue is solved, I’ll close the issue in this repo and reopen the issue in the other repo. Thanks for letting me know.

I used the basic websocket example from that repository (https://github.com/gd-com/examples) and
added two clients that used the exact same script except for the message that they are sending to the server.
Client1 sends: I AM NUMBER ONE
Client2 sends: ALWAYS SECOND PLACE

As you can see in the screenshot, this works without any problem and the messages of the clients are displayed correctly.

I am using the server supplied with this repository (the nodejs one found in the /websocket/basic/server) and ran it with «npm start» (after installing the prerequisite modules @gd-com/utils and ws)

What version of Godot are you using? (I’m using 3.1.1 stable)
What version of nodejs? (I’m using 10.15.3 -lts)
What is your OS? (I’m on Windows 10)

EDIT: I also tried to run 2 Godot instances at once (each with 2 clients) and this also works without a hitch. I don’t really know what else to test?

What version of Godot are you using? (I’m using 3.1.1 stable)
What version of nodejs? (I’m using v8.16.0 (Thank you for letting check my node version to see how old it is 🙂 ))

What is your OS? (Ubuntu 16.04 LTS)

From the screenshot, I think this error only happens on Linux, since it seems a unix thing, correct me if I’m wrong. Maybe on mac too since it uses unix?

The first client connects, on the left, then I try to connect the one on the right, I get an error and the one on the left shows an error then too.

Could you try updating your nodejs?

If the problem persists after this upgrade, I can also check it on my linux machine (Arch Linux)
to see if the problem is unique to Linux machines.

Regarding the «unix» error: I get the exact same error as well on my Windows 10 when I screw up my GDNative scripts. So this «unix» error is not something that only appears on Linux 😄

ok will let you know tomorrow for sure.

When running multiple Godot editors it is also important to change the debugger port for one of the editors.
Currently both editors are trying to listen to port 6007 to find out any errors from the running game instance and this gives an error in one of the editors, like this:
Error listening on port 6007

Change you debugger port by going to:
Editor Settings -> Network -> Debug
and change the remote port there to 6008 (or anything else than 6007)

The error is still there after upgrading to node 10 lts.

There’s nothing in Editor Settings -> Network -> Debug

Be sure to remove the «net» search term! Otherwise the debug port options won’t show! 😄

Wow! That’s worthy of a second issue just to fix the search 🙂

Regarding the websockets, it’s fixed, thanks a lot seriously, no one could fix it but you, I posted it on reddit Godot group twice where hundreds of users are online always, on facebook and here, you were the only one who solved it 🙂

I hope you are paid very very well in your job because you deserve it, you are very helpful and just provided premium support, you deserve the very best this life has to give.

The only other github repo I could think of that gives the support you gave is VSCode, but those are microsoft employees who are getting paid.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Error listening on port 6007 #41650

Godot version: 3.2.2 stable mono

Issue description:
Everytime when I launch an android debug build with custom build enabled direct to my smartphone and/or virtual test device godot can no longer connect to port 6007 if I deploy a second time. Due to this I get no prints or debug informations.

On 2nd build also play button, webbuild and such builds won’t produce any prints or debug informations with same error.

I have to restart my computer to get rid of the blocked port. If I launch direct to android again I have to restart again.

Error: «error listening on port 6007».

Even if I kill the pid sitting on this port the problem won’t vanish.

Steps to reproduce:
Build a project with custom build checked per direct deploy to any android device. Do it again and the error appears.

Minimal reproduction project:
simple 2d scene with custom build checked for android.

The text was updated successfully, but these errors were encountered:

Error still not fixed. Changing remote port to 6008 removes the error but the debugger still gets disconnected for me, and then the last output is «Connection Taken».

This may be fixed by #37067 if it’s merged.

Need to debug a custom build with an Android local notification plugin and hard to do that without the debugger working 😄 Fingers crossed.

I also have this issue. Hoping it gets resolved with the PR above.

I have to restart my computer to get rid of the blocked port.

Signing out and in again gets rid of it as well.

For the time being, you can edit the port directly in the editor settings. You don’t need to sign in and out nor restart your machine.

For the time being, you can edit the port directly in the editor settings. You don’t need to sign in and out nor restart your machine.

Yeah you can iterate hundrets of ports and than you can down-iterate after restart. thats not realy a solution, thats a work around with risks.

For the time being, you can edit the port directly in the editor settings. You don’t need to sign in and out nor restart your machine.

Yeah you can iterate hundrets of ports and than you can down-iterate after restart. thats not realy a solution, thats a work around with risks.

@lefavilla That is indeed true. It was never meant as go-to solution. It is a workaround, yes, but a better one than restarting your computer. I only meant to give an easier workaround for people, who may not know the configurability of the debugger port. FYI the mentioned PR does excactly what you can do by hand, only that it provides better usability 😃

I’m still having this error as of 3.3.1

AFAIK there is a fix in 3.4. (in the 3.x branch I used yesterday to compile the engine)

AFAIK there is a fix in 3.4. (in the 3.x branch I used yesterday to compile the engine)

Indeed, #37067 has been merged in the 3.x branch but hasn’t been cherry-picked to the 3.3 branch so far. In the meantime, there is a workaround you can use with an editor plugin: #37067 (comment)

In 3.4.2 after one deploy to Android, I get this error:

» Remote debugger failed listening on port: 6007 Retrying on new port: 6008
Connection Taken»

but the debugger still doesn’t connect on the new port.

In 3.4.2 after one deploy to Android, I get this error:

» Remote debugger failed listening on port: 6007 Retrying on new port: 6008 Connection Taken»

but the debugger still doesn’t connect on the new port.

Does this occur when running a project from two different editor instances on your own machine?

Does this occur when running a project from two different editor instances on your own machine?

Happens with 1 or 2 instances.

However, I just noticed it only happens when «Use Custom Build» is enabled in Export (I’m using the Google Play Billing Plugin).
When building the APK, I also get an error from Gradle that it could not reuse a stopped process or something like that (would need to record screen if more information is required as it only shows briefly).

Also changing the port, like suggested above, does not fix it — debugger gives «Connection taken» and does not work, neither on further Android deploys nor any other ones, so after one custom build Android deploy the debugger is gone unless you restart the pc.

I hope this can be fixed, as it makes debugging almost impossible when using custom builds on Android, forcing you to having to restart your pc after every deploy.

so after one custom build Android deploy the debugger is gone unless you restart the pc.

As a workaround, you can probably kill the debugger process using a task manager.

so after one custom build Android deploy the debugger is gone unless you restart the pc.

As a workaround, you can probably kill the debugger process using a task manager.

I wanted to do that, but after killing every Godot process (which was not enough) I did not found any more that I could relate to it. Is the debugger a separate process in itself, if so what is it called?

Is the debugger a separate process in itself, if so what is it called?

It may be an adb process or something like that.

Killing adb doesn’t free it up, andd I can’t find any process that might be related to it.

There are ways to check which software eats the port. If you use Windows, follow this guide: https://www.maketecheasier.com/check-ports-in-use-windows10/#:

Also getting this on 3.4.2 stable. netstat showing some process using the port but I can’t kill them. The only workaround so far that has worked for me is from here by setting remote host to 0:0:0:0:0:0:0:1 and the remote port to a different one in editor > editor setting > network https://godotforums.org/discussion/23142/port-6007-error-when-disconnecting-android-test-device

hello ,I got this problem too. and have to restart computer to fix it.
maybe it is because I first open AndroidStudio and run godot ,and Androidstudio somehow block godot from communicating the app

I also started to get this error when i run debug on android over usb (v 3.4.3).
«Remote debugger failed listening on port: 6007 Retrying on new port: 6008»

It starts to appear after ending of the first debugging session:

1. run debug for the first time: everything is ok, breakpoints work, I can iterate over the functions.
2. stop the program in android (swipe it in recent apps)
3. run debug again:
   • start to get error «»Remote debugger failed listening on port: 6007. «
   • debug is not available, I don’t get any output from the app in the Output window
   • as I can see, breakpoints work (because program freezes if I set any breakpoint), but I have no control over the debugging process, because editor didn’t connect to the running app.

My workaround is the following (killing the gradle daemon):

• I run cmd in separate window
• execute the command WMIC PROCESS where «Name like ‘java%’ AND CommandLine like ‘%GradleDaemon%’» Call Terminate
• after this debug stars to work but only the first time.
• after ending of debugging session, I have to kill gradle daemon again.

Reply to myself: after project reload remote debugger on android started to work normaly.

I’ve just hit this exact problem on Godot 3.5 Stable (downloaded from official Godot site). Have «custom build» switched on for GodotGooglePlayBilling. Killing Java.exe allows the console output to come back, but breakpoints still don’t work. Restarting Godot makes no difference to breakpoints.

I can confirm this is still happening with Godot 3.5 stable, custom build. I can use the command yurii-sio2 posted above (#41650 (comment)) to get the debugger working again

When I turn off the custom build option, the debugger correctly disconnects.

Источник

Running game from VSCode and remote nodes #216

If we run the game from VSCode, we are not able to see remote nodes.

The text was updated successfully, but these errors were encountered:

@rohanrhu Can you clarify what you mean? When debugging the game there is an active scene tree that mirrors what the Remote panel in the editor does. It does not automatically refresh but there is a refresh button.

Unless you mean Remote nodes as something else?

VSCode’s scene tree is empty when i run the game. (Also Godot’s is empty too.)

Seeing the same behavior. Since I can’t even see a remote scene tree in Godot itself, I suspect a Godot issue. I do see «Failed to connect to port 6007» or something similar when launching a game from within the editor. Something is definitely listening on 6007. I also just tried downgrading to Godot 3.2.1 with no change. This definitely worked at one point but doesn’t anymore.

Is there a way to get a debugging session from the console, since the GUI isn’t working?

Or is this being tracked in Godot? A quick skim of open issues didn’t reveal anything.

@rohanrhu @ndarilek Can you post your launch.json file?

When you say that there’s no Remote tree in Godot, do you mean that when you debug Godot without the use of VSCode, even Godot doesn’t show the remote scene tree link?

Do breakpoints work?

If not, can you try going into the launch.json and change the port from 6007 to something else? Like 32753 or something else totally arbitrary that is unlikely to be in use, see if that works.

Sorry, @ndarilek and @rohanrhu , life got in the way. Can you try the custom VSIX I have in a comment here?

Duplicate of #222.
Can’t reproduce the issue on my hand.

Closing per @linkpy’s comment.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

rohanrhu opened this issue 3 years ago · comments

Your program can also call Visual Studio Code with the debug information to ask LLDB to connect as described here. This was tested with GDScript/Rust GDNative on Linux, but should work for GDExtensions & C++ or C# too. Option 1 should work on any Windows, MacOS or Linux. Option 2 is more elegant, but it may only work with Linux & MacOS.

Option 1

Add a callback from your GDNative binary

Rust:

#[cfg(debug_assertions)]
{
    let url = format!("vscode://vadimcn.vscode-lldb/launch/config?{{'request':'attach','pid':{}}}", std::process::id());
    std::process::Command::new("code").arg("--open-url").arg(url).output().unwrap();
    std::thread::sleep_ms(1000); // Wait for debugger to attach
}

C:

char command[256];
snprintf(command, sizeof(command), "code --open-url "vscode://vadimcn.vscode-lldb/launch/config?{'request':'attach','pid':%d}"", getpid());
system(command);
sleep(1); // Wait for debugger to attach

Option 2

For Linux or MacOS, use a preLaunchTask to launch a background task that uses pgrep to find the correct godot process and call VS Code. Although it’s called pre-launch, it actually sleeps a couple seconds to wait for Godot to launch and get its Process ID.

Add this to launch.json:

    // This waits a second and calls VS code to attach lldb
    "preLaunchTask": "Attach LLDB Later"

And then add this to tasks.json:

{
    "label": "Attach LLDB Later",
    "type": "shell",
    "command": "/bin/bash",
    // Called from a preLaunchTask.  First wait for it to start up.
    // Then call VS code and tell it to attach with the LLDB debugger.
    "args": ["-c", "echo Waiting for launch...;sleep 2; code --open-url "vscode://vadimcn.vscode-lldb/launch/config?{\"request\":\"attach\",\"pid\":$(pgrep --full --newest godot.\*remote-debug)}";echo LLDB attached."],
    "isBackground": true,
    // All this is needed so VSCode doesn't complain about the background task.
    "problemMatcher": [
        {
        "pattern": [
            {
            "regexp": ".",
            "file": 1,
            "location": 2,
            "message": 3
            }
        ],
        "background": {
            "activeOnStart": true,
            "beginsPattern": ".",
            "endsPattern": ".",
        }
        }
    ]
},

The «pgrep —full —newest godot.*remote-debug» will search for the correct godot process. The VSCode Godot Plugin runs the editor too, but this doesn’t have «remote-debug» in the full command line. By making this a background task, it solves the catch-22. The problem matcher looks for any output, even if it just says it’s waiting.

Now I can set a breakpoint in both GDScript and the GDNative plugin in the same VSCode editor, and both breakpoints work.