godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
86.57k stars 19.29k forks source link

Remote Debugger only working once #91359

Open Nitwel opened 2 months ago

Nitwel commented 2 months ago

Tested versions

System information

Godot v4.2.2.stable - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3080 (NVIDIA; 31.0.15.5161) - Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz (16 Threads)

Issue description

I'm working on https://github.com/Nitwel/Immersive-Home, an app for XR Headsets, meaning I have to export to Android. When I start Godot the first time and then run the "Remote Debug" option, everything works as expected in that the remote debugger works fine.

When exporting a second time using the "Remote Debug" button, I can see that Godot sets all params properly when exporting:

0 param: --remote-debug
1 param: tcp://localhost:6008
2 param: --xr_mode_openxr
3 param: --use_immersive
Installing to device (please wait...): Oculus Quest 3
--- Device API >= 21; debugging over USB ---
--- DEVICE API >= 21; DEBUGGING OVER USB ---
Reverse result: 0

But the remote debugger just wont ever start again. Only after completely restarting Godot it works again, but only the first time.

I should add that I've asked @BastiaanOlij about this problem already and he mentioned that he never had that problem.

Steps to reproduce

  1. Open Godot
  2. Make sure "Debug > Deploy with Remote Debug" is enabled
  3. Export to Android using "Remote Debug"
  4. Everything works
  5. Export to Android using "Remote Debug" again
  6. Debugger doesn't start

Minimal reproduction project (MRP)

demo.zip Make sure to install godotopenxrvendors. (it was to large for upload)

BastiaanOlij commented 2 months ago

cc @m4gr3d any ideas what could be causing this?

I've had in the past that remote debugging didn't work at all, but that seems to be solved in the current master.

@Nitwel how do you exit you app on the Quest? I have found that if I keep it running before starting another debug session, it can sometimes have issues. But I haven't experienced this particular problem.

p.s. love immersive home, such a cool project.

Nitwel commented 2 months ago

Haha, thanks! ❤️

That was also my guess that the session doesn't properly close thus the port on the headset is blocked and the next deploy can't connect the debugger to the right process, though that is really hard for me to debug.

When creating the demo project for this issue, I think it was working properly for the first few runs running on an nearly empty game. I also tried running a clean scene in the Immersive Home project and there it wasn't working properly at all. (I was trying to make sure that it is not my project that is messing stuff up but that it is possibly something related to my PC and it seems like so)

After that even the demo project was only working on the first time. Let me know if there are ways for me to debug this as I can't find any error message and I would love to get that fixed as debugging bugs that happen on Quest but not on PC are the worst. 😅

Nitwel commented 2 months ago

Okay, after some more observing I noticed the following pattern:

  1. Start Godot with "Deploy with Remote Debug" enabled, it only works the first time.
  2. Start Godot with "Deploy with Remote Debug" disabled, it works 100% of the time.

No clue why this is the case but at least I now have a temporary solution to this problem.

0xtito commented 1 month ago

cc @m4gr3d any ideas what could be causing this?

I have been experiencing the some problem when using the Remote Bugger while exporting to Android (Quest 3).

I am not 100% sure, but I think the problem may stem from the OpenJDK not properly shutting down.

When starting the project via Remote Debugging for the first time, everything logs as expected. However, when I shut it down and then run it again, I get the same log as @Nitwel. However, when I check my task manager, I see that OpenJDK is still running (at the very least still taking up a good chunk of memory). So I have force closed it, and then when I run the project again via remote debugging, everything is properly logging.

So maybe jdk is not being properly shut down when the application is closed on the headset?

Maybe we can see if this is happening to you as well @Nitwel?

I've had in the past that remote debugging didn't work at all, but that seems to be solved in the current master.

I am using master as well, specifically at commit 214968243c442c0fdcbdfef23943c1547aeafdbc (May 21)

EDIT: I am working on windows. If necessary, I can make a separate issue and make more detailed comments on the steps and my config

Nitwel commented 1 month ago

Can confirm that terminating the OpenJDK task fixes it. Would love to see a fix before 4.3 as it should be fairly easy to make sure that the task is properly killed and is quite the annoyance when exporting to android.

m4gr3d commented 1 month ago

I have been able to repro the issue on a Quest Pro device; all attempts to repro the issue on a regular Android device (Samsung S8 tablet in this case) failed however, which suggests it may be a Quest only issue.

cc @dsnopek @devloglogan

dsnopek commented 3 weeks ago

While I personally do occasionally have issues with remote debugging not working, for me it's pretty random (like 1 in 100 runs it decides not to work), and I can't reliably reproduce it like described here. However, I'm on Linux (Ubuntu 22.04) and it seems like the folks having this problem are on Windows. I'll try on Windows in a bit and see if I can reproduce it there.

dsnopek commented 3 weeks ago

Hm, I'm not able to reproduce on Windows either. :-/ I tried with Godot 4.2.2, with both the Quest 3 and Quest Pro, and remote debug was working for me on subsequent runs of the app (I'm using the MRP from this issue's description).

For the folks who are seeing this issue:

Nitwel commented 3 weeks ago

It's pretty easy to determine if the Remote Debugger is not working as the "Remote Scene" tab wont show, no logs will be visible and in general, nothing in Godot will happen that normally would happen when you run it local or remote.

> java --version
openjdk 17.0.9 2023-10-17
OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode, sharing)

> sdkmanager --list
Installed packages:
  Path                 | Version      | Description                             | Location
  -------              | -------      | -------                                 | -------
  build-tools;33.0.2   | 33.0.2       | Android SDK Build-Tools 33.0.2          | build-tools\33.0.2
  build-tools;34.0.0   | 34.0.0       | Android SDK Build-Tools 34              | build-tools\34.0.0
  cmake;3.10.2.4988404 | 3.10.2       | CMake 3.10.2.4988404                    | cmake\3.10.2.4988404
  cmake;3.22.1         | 3.22.1       | CMake 3.22.1                            | cmake\3.22.1
  cmdline-tools;latest | 11.0         | Android SDK Command-line Tools (latest) | cmdline-tools\latest
  ndk;23.2.8568313     | 23.2.8568313 | NDK (Side by side) 23.2.8568313         | ndk\23.2.8568313
  platform-tools       | 34.0.5       | Android SDK Platform-Tools 34.0.5       | platform-tools
  platforms;android-33 | 3            | Android SDK Platform 33                 | platforms\android-33
  platforms;android-34 | 3            | Android SDK Platform 34                 | platforms\android-34
m4gr3d commented 3 weeks ago

How are you validating whether remote debug is working or not? (I've tried with print() messages to see if they appear in Godot's "Output" area, and setting breakpoints - both are working for me)

When I was able to repro the issue, the breakpoints would work the first time, but then stop working on subsequent pushes to the device.

dsnopek commented 3 weeks ago

Hm, ok, thanks!

For me, breakpoints and log output are definitely working on all runs (not just the first one). It does look like I'm using a slightly newer OpenJDK and platform-tools than @Nitwel, although, either I'd need to downgrade or @Nitwel to upgrade, in order to see if that's related to the problem.

I think @devloglogan was seeing this issue on his system, so perhaps he'll be able to help implement a solution.

devloglogan commented 3 weeks ago

I'm certain I've experienced this problem at some point in the past. However, when attempting to reproduce using a Quest 2 on both my laptop (Windows 11, OpenJDK 17.0.10, Android SDK API 34, platform-tools 34.0.5) and my desktop (Windows 11, OpenJDK 17.0.11, Android SDK API 33, platform-tools 35.0.1), I'm not able to reproduce.

Even when downgrading my OpenJDK and platform-tools versions to the same as @Nitwel, still unable to reproduce.

0xtito commented 3 weeks ago

Hm, I'm not able to reproduce on Windows either. :-/ I tried with Godot 4.2.2, with both the Quest 3 and Quest Pro, and remote debug was working for me on subsequent runs of the app (I'm using the MRP from this issue's description).

For the folks who are seeing this issue:

  • What version of OpenJDK are you using? (I'm on 17.0.11)
  • What version of the Android SDK and platform-tools are you using? (I'm using API 34, with platform-tools 35.0.1)
  • How are you validating whether remote debug is working or not? (I've tried with print() messages to see if they appear in Godot's "Output" area, and setting breakpoints - both are working for me)
❯ java --version
openjdk 17.0.11 2024-04-16
OpenJDK Runtime Environment Temurin-17.0.11+9 (build 17.0.11+9)
OpenJDK 64-Bit Server VM Temurin-17.0.11+9 (build 17.0.11+9, mixed mode, sharing)

❯ sdkmanager --list
Warning: This version only understands SDK XML versions up to 3 but an SDK XML file of version 4 was encountered. This can happen if you use versions of Android Studio and the command-line tools that were released at different times.
[=======================================] 100% Computing updates...
Installed packages:
  Path                 | Version      | Description                             | Location
  -------              | -------      | -------                                 | -------
  build-tools;33.0.2   | 33.0.2       | Android SDK Build-Tools 33.0.2          | build-tools\33.0.2
  build-tools;34.0.0   | 34.0.0       | Android SDK Build-Tools 34              | build-tools\34.0.0
  cmake;3.10.2.4988404 | 3.10.2       | CMake 3.10.2.4988404                    | cmake\3.10.2.4988404
  cmake;3.22.1         | 3.22.1       | CMake 3.22.1                            | cmake\3.22.1
  cmdline-tools;latest | 13.0         | Android SDK Command-line Tools (latest) | cmdline-tools\latest
  emulator             | 34.2.13      | Android Emulator                        | emulator
  ndk;23.2.8568313     | 23.2.8568313 | NDK (Side by side) 23.2.8568313         | ndk\23.2.8568313
  platform-tools       | 35.0.1       | Android SDK Platform-Tools              | platform-tools
  platforms;android-33 | 3            | Android SDK Platform 33                 | platforms\android-33
  platforms;android-34 | 3            | Android SDK Platform 34                 | platforms\android-34
  sources;android-33   | 1            | Sources for Android 33                  | sources\android-33
  sources;android-34   | 2            | Sources for Android 34                  | sources\android-34

For me, I know it is not working because the only thing I see is this (even though I have many print statements that should be getting logged):

0 param: --remote-debug
1 param: tcp://localhost:6008
2 param: --xr_mode_openxr
3 param: --use_immersive
Installing to device (please wait...): Oculus Quest 3
--- Device API >= 21; debugging over USB ---
--- DEVICE API >= 21; DEBUGGING OVER USB ---
Reverse result: 0

After running my game after the first time. This is the same message that Nitwel is getting.

This error also consistently happens on my MacBook Air M2, 2022 running 14.4.1.

devloglogan commented 3 weeks ago

Strangely enough, this issue is now taking place on my desktop again. Like mentioned above, when terminating the OpenJDK task, it will then work. On my machine, this is what is passed to the command line to start the process:

"C:\Program Files\Eclipse Adoptium\jdk-17.0.11.9-hotspot\bin\java.exe" --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED -Xmx4536m -Dfile.encoding=windows-1252 -Duser.country=US -Duser.language=en -Duser.variant -cp C:\Users\langl\.gradle\wrapper\dists\gradle-8.2-bin\bbg7u40eoinfdyxsxr3z4i7ta\gradle-8.2\lib\gradle-launcher-8.2.jar -javaagent:C:\Users\langl\.gradle\wrapper\dists\gradle-8.2-bin\bbg7u40eoinfdyxsxr3z4i7ta\gradle-8.2\lib\agents\gradle-instrumentation-agent-8.2.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 8.2

The command is starting a gradle daemon. So, using a previously running gradle daemon seems to be related to the problem.

The above command is constructed and executed in this function.