Generating a support package fails on wgpu-related step

[hypevhs]

Acknowledgements

• I have searched for duplicate or closed bug reports
• I understand that I am supposed to provide my own legitimately obtained copy of the game
• If possible, I've attached the support package zip file to the issue see how here

Attach Support Package / Log Files (drag and drop)

No support package is created.
My logfile: 2024-10-06.log
The crash log placed on my desktop when attempting to generate the support package: og-launcher-crash.log
My vulkaninfo: vulkaninfo.txt

Describe the Bug

I'm unable to generate a support package from the Help page. The logs mention wgpu, egl, and failing to find Vulkan extensions that all definitely are supported by my AMD GPU.
I am running Wayland (KDE KWin, though XWayland is available, which is what OpenGOAL-Launcher is using).

How To Reproduce

1. Launch v2.5.1 AppImage
2. Navigate to Help page
3. Click Download Support Package
4. Select a reasonable directory e.g. $HOME
5. Click Save
6. Observe how:
   1. The Download Support Package button keeps spinning until you leave the page
   2. No support package ZIP is saved
   3. A file og-launcher-crash.log is saved to my desktop

Operating System

Arch Linux

Launcher Version

v2.5.1

Tooling Version

v0.2.17

[hypevhs]

The behavior is the same when running the entire KDE desktop under X11, so it is unlikely to be a Wayland-related issue.

--
The behavior is very different when built from source in Tauri dev mode:
I get a proper error message saying "Unable to create support package", and still no ZIP file is created. In fact, this button seems to put the whole launcher in an unstable state, where just moving the mouse around on the page will spam this log line several times a second:

[22:16:03][wgpu_hal::gles::egl][ERROR] EGL 'eglSwapInterval' code 0x300d: eglSwapInterval

Log file for when in Tauri dev mode: 2024-10-06.log

--
I have also copied out this GPUInfo code into a 10-line Rust PoC, with the same wgpu version, and it seems to print driver info fine, so maybe not an issue from wgpu itself.

[xTVaser]

The use of wgpu is pretty small and basic, it's concerning that you can't reproduce the same problem in a PoC in the same environment.

Realistically that probably means there's nothing I can do from my end, unfortunately wgpu::Instance::default(); panics, which likely puts the application into an unrecoverable/bad state (I now see that our panic hook should terminate the program after logging/etc). But if that panic only happens when ran via the launcher, then there's too many layers involved that are outside of our control.

Perhaps it's time to look for yet another solution than using wgpu (i briefly started looking at luminance), but querying for this information in a cross-platform way for all GPU vendors is such a headache, I can't say I'm optimistic about spend time on trying that.

If this is as annoying to solve as it seems, then it's probably not worth investigating as it's hopefully an isolated incident. The support package feature is there to reduce friction when helping users that don't know how to find and share log files, which is not a problem here :)

[trippjoe]

Can you please modify cargo.toml by adding wgpu = { version = "22.1.0", default-features = true }, and then build, test and report back on the results?

[hypevhs]

I don't think changing wgpu's default-features had any effect.

--

All the eglSwapInterval error lines come from how wgpu, when compiled in rust dev profile, enables the +debug EGL context, which enables EGL debug output. I guess it never disables it - no big deal there.

Whatever the wgpu issue is, only happens in the official AppImage (v2.5.2). When building from my up-to-date Arch, I can get past the wgpu step when using AppImage, or cargo build, or tauri dev, etc. So maybe it's a bug introduced by all the old Ubuntu libs.

--

There is a further issue with how the zip is moved to the user-specified location after being created, but I don't think it warrants another issue:
Rust docs on fs::rename says "This will not work if the new name is on a different mount point." So this line in support.rs will fail because /tmp/.tmpexLWFn and /home/hype/opengoal-support-package.zip will be on different mount points. Maybe fs::copy works instead?