Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug][v2][linux] fails to run on Fedora 40 tauri appimage built on GitHub Actions #10749

Closed
anatawa12 opened this issue Aug 23, 2024 · 9 comments
Labels
platform: Linux status: needs triage This issue needs to triage, applied to new issues status: upstream This issue is blocked by upstream dependencies and we need to wait or contribute upstream fixes type: bug

Comments

@anatawa12
Copy link
Contributor

anatawa12 commented Aug 23, 2024

Describe the bug

fails to run on Fedora 40 tauri appimage built on GitHub Actions.

in console output, those log are shown

Cannot get default EGL display: EGL_SUCCESS
Cannot create EGL context: invalid display (last error: EGL_SUCCESS)
Violación de segmento (`core' generado)

Downstream issue: vrc-get/vrc-get#1405

Reproduction

  1. Build tauri app with github actions. I made this for testing
  2. fails to launch tauri app due to error above

Expected behavior

No response

Full tauri info output

[✔] Environment
    - OS: Mac OS 14.4.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.81.0-beta.2 (08328a323 2024-07-25)
    ✔ cargo: 1.81.0-beta.2 (a2b58c3da 2024-07-16)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: beta-aarch64-apple-darwin (default)
    - node: 22.6.0
    - pnpm: 8.15.4
    - npm: 10.8.2

[-] Packages
    - tauri [RUST]: 2.0.0-rc.6
    - tauri-build [RUST]: 2.0.0-rc.6
    - wry [RUST]: 0.42.0
    - tao [RUST]: 0.29.1
    - tauri-cli [RUST]: 2.0.0-rc.3
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-rc.7

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: web

Stack trace

No response

Additional context

No response

@anatawa12 anatawa12 added status: needs triage This issue needs to triage, applied to new issues type: bug labels Aug 23, 2024
@FabianLars FabianLars added status: upstream This issue is blocked by upstream dependencies and we need to wait or contribute upstream fixes platform: Linux labels Sep 2, 2024
@naman-crabnebula
Copy link
Contributor

Hi!

It is working fine here on Fedora 40 ( in VM hosted on Arch Linux via VirtualBox )

image

Are you using wayland by any chance?

@anatawa12
Copy link
Contributor Author

vrc-get/vrc-get#1405 (comment)

I'm using Fedora 40, running Wayland.

Original reporter is using Wayland

@FabianLars
Copy link
Member

It works on my Fedora system (a real one, not a VM) too but the error somewhat sounds like something nvidia specific which i can't test.

Can you ask your users to run the app with the WEBKIT_DISABLE_COMPOSITING_MODE=1 and/or WEBKIT_DISABLE_DMABUF_RENDERER=1 env var(s) set? This typically helps with nvidia specific issues (though this specific error is new to me so no promises)

@debbie-drg
Copy link

Original reporter here! The system where I was having the issue does indeed have an nvidia GPU. I've just tried running the Tauri simple app on a laptop without an nvidia GPU also running Fedora 40 and the application indeed works. I'll try those env variables on my other system with the nvidia GPU and report back once I get home in a few hours.

@debbie-drg
Copy link

Running the application using the WEBKIT_DISABLE_DMABUF_RENDERER=1 env variable works.

@FabianLars
Copy link
Member

Okay that's good i guess. It also means that this issue isn't really in our hands though :/ (as long as we keep using webkitgtk).

@FabianLars FabianLars closed this as not planned Won't fix, can't repro, duplicate, stale Sep 3, 2024
@anatawa12
Copy link
Contributor Author

Is there anything I can do for improving this problem?

@FabianLars
Copy link
Member

You could use std::env::set_var to set said env var for every user of your app. Of course that reduces performance for those where the renderer does work fine.

Alternatively, we can only wait for new webkitgtk releases. They are actively working on the renderer (which at the same time is the reason why webkitgtk broke for so many people in the first place).

@anatawa12
Copy link
Contributor Author

I thought "as long as we keep using webkitgtk" means it's not fixable due to architecture or something hard to fix in webkitgtk.
but if it might be fixed, I'll just just wait for newer release. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform: Linux status: needs triage This issue needs to triage, applied to new issues status: upstream This issue is blocked by upstream dependencies and we need to wait or contribute upstream fixes type: bug
Projects
None yet
Development

No branches or pull requests

4 participants