OpenXR project crashes on Windows when using OpenXR 1.0.29 or later, compiled with mingw-gcc #83674
Comments
|
I don't have an XR device. But simply opening this project with 4.2 beta2 does work. It takes a bit longer than I would expect (probably just the first time), but it happens. And there is some issue logged: Though this may be just about me not having an XR device. Specs:
Edit: Try launching Godot from the command line with the |
To test this hypothesis, I've made a build of 4.2-beta2 with #82582 reverted. Could you test it and let me know if that solves the issue? https://downloads.tuxfamily.org/godotengine/testing/Godot_v4.2-beta2_windows_openxr_1.0.28.zip |
|
@akien-mga It indeed solves the issue, so that would seem to support the hypothesis. In custom build: 4.2.Beta.2.-.OpenXR.1.0.28.test.mp4 |
|
I can confirm using the Godot_v4.2-beta2_windows_openxr_1.0.28 fixes my memory corruption issue on:
|
|
I wonder what the source of this is as I've been using my own builds with OpenXR 10.0.30 without problems for some time now. What do we do different in our build process that would introduce this instability? @akien-mga we should and see if the issue is fixed with OpenXR 10.0.31, we're starting to roll out extensions that require the newer OpenXR version. We can probably get away with 28 for the 4.2 release if we can't figure this out in time, but 4.3 likely will need to run a newer version of OpenXR. |
As @YuriSizov already mentioned, always use |
I will keep that in mind. This is the console output for the OpenXR 1.0.30 beta 2 version: Details
D:\Projects\Godot>Godot_v4.2-beta2_win64_console.exe --verbose TextServer: Primary interface set to: "ICU / HarfBuzz / Graphite (Built-in)". It simply stops after "OpenXR: Enabling extension XR_KHR_vulkan_enable2" This is the console output for the OpenXR 1.0.28 beta 2 version: Details
D:\Projects\Godot>godot.windows.editor.x86_64.console.exe --verbose TextServer: Primary interface set to: "ICU / HarfBuzz / Graphite (Built-in)".
TextServer: Primary interface set to: "ICU / HarfBuzz / Graphite (Built-in)". PS: Thanks to everone involved for their hard work and dedication towards making this the great engine that it is. EDIT: Updated the console output for the 1.0.30 version. I think I accidentily copy-pasted some duplicate lines in there. |
Official builds are made with mingw-gcc, and LTO. So they can have different compilation/optimization bugs than MSVC. Seems like openxr 1.0.30 added something that triggers a compiler bug. |
|
I've made a few more builds to test whether upgrading mingw-gcc (with versions from Fedora 39 instead of Fedora 36) or OpenXR (both with Fedora 36 and 39 toolchains) helps. Could you test them and let me know if they work?
|
|
All three of those test builds crash at the same point right after the |
|
Thanks! I'll make a test build with openxr 1.0.29 tomorrow, and based on the results roll back to 1.0.28 or 1.0.29 for 4.2. Then we can see why it crashes in newer versions and report it upstream. |
|
All three test builds also crash right after "OpenXR: Enabling extension XR_KHR_vulkan_enable2" for me. |
|
Another test build with openxr 1.0.29, built on Fedora 36 (same as all previous 4.2 builds): The diff between 1.0.29 and 1.0.30 isn't big, so I don't have high hopes this version works. But it's worth testing to know if we should revert to 1.0.28 or 1.0.29. |
|
Unfortunately, I get the same result as with the other test builds. |
|
Yup - same with me - the new one crashes at the same spot. |
Reverts godotengine#82582. Works around godotengine#83674. Users tested 1.0.29, 1.0.30, and 1.0.31, which all triggered the same issue, with both mingw-gcc from Fedora 36 and Fedora 39.
|
I'm reverting to 1.0.28 with #83829, so this should solve the issue for 4.2 beta 3 and later. I'll keep this issue open to further investigate why it crashes, so we can get it fixed and eventually update to a newer openxr SDK. Might not have time to look into it before the 4.2 release so I'm putting this on the 4.3 milestone. |
akien-mga
changed the title
|
Could I get this build tested? It's upgrading to 1.0.31 again, but with a buildsystem fix. We were apparently compiling both the new and the old versions of the dispatch table introduced in 1.0.29, which is the kind of stuff that can trip up compilers/optimization. Now we only compile the new one. Edit: I named that zip |
|
Just tested this build running all three renderers and using Windows 10, AMD Ryzen 87, NVidia 4070 Ti, Running PCVR Quest Pro over Airlink |
|
The new build runs the original MRP just fine on my system. |
Reverts godotengine#82582. Works around godotengine#83674. Users tested 1.0.29, 1.0.30, and 1.0.31, which all triggered the same issue, with both mingw-gcc from Fedora 36 and Fedora 39.
Godot version
v4.2.beta2.official [f8818f8], v4.2.beta1.official [b137180], v4.1.1.stable.official [bd6af8e]
System information
Windows 10, Vulkan Forward+, Nvidia RTX3060Ti Game-ready driver 537.58, SteamVR 2.0.6, Windows Mixed Reality for SteamVR 1.3.73, HP Reverb G2 headset.
Issue description
When running a simple OpenXR project in Godot 4.2 Beta 2, a project that runs fine 4.1.1 Stable and 4.2 Beta 1, the project silently fails to launch and no OpenXR / Vulkan version info is printed to the console.
In the included videos I demonstrate the issue by running the project directly from the manager, but the behaviour is the same when run from the editor.
Perhaps the issue is related to the recent update to OpenXR-SDK 1.0.30 when using Windows Mixed Reality (it seems the update was mainly tested on Meta / Android)? Version 1.0.31 has just been released and mentions some compatibility improvements.
In Beta 1:
Godot.4.2.beta.1.-.steamvr_openxr_wmr.test.mp4
In Beta 2:
Godot.4.2.beta.2.-.steamvr_openxr_wmr.test.mp4
Steps to reproduce
Run the attached MRP in Godot 4.1.1 Stable or 4.2 Beta 1.
Observe that the project launches and runs correctly.
Run the MRP in Beta 2.
Observe that the project fails to launch.
Observe that no OpenXR / Vulkan info is printed to the console.
Minimal reproduction project
Beta 2 OpenXR Test.zip
The text was updated successfully, but these errors were encountered: