Crash with Flatpak on Fedora 40 on wayland
Describe the bug The app crashes when starting on Fedora 40 with flatpak. I'm using KDE, and it seems the app cannot connect to the x11 fallback server (although the permission is enabled)
$ flatpak run com.jetpackduba.Gitnuro
[LOG] OS - OS is linux
log4j:WARN No appenders could be found for logger (org.slf4j).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set,
but this program performed an operation which requires it.
at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:58)
at androidx.compose.ui.window.LayoutConfiguration_desktopKt.getGlobalDensity(LayoutConfiguration.desktop.kt:41)
at androidx.compose.ui.window.Application_desktopKt$awaitApplication$2$1$2$1.invoke(Application.desktop.kt:226)
at androidx.compose.ui.window.Application_desktopKt$awaitApplication$2$1$2$1.invoke(Application.desktop.kt:221)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jb.kt:107)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jb.kt:33)
at androidx.compose.runtime.ActualJvm_jvmKt__ActualJvm_jvmKt.invokeComposable(ActualJvm.jvm.kt:36)
at androidx.compose.runtime.ActualJvm_jvmKt.invokeComposable(Unknown Source)
at androidx.compose.runtime.ComposerImpl.doCompose(Composer.kt:3595)
at androidx.compose.runtime.ComposerImpl.composeContent$runtime(Composer.kt:3522)
at androidx.compose.runtime.CompositionImpl.composeContent(Composition.kt:743)
at androidx.compose.runtime.Recomposer.composeInitial$runtime(Recomposer.kt:1122)
at androidx.compose.runtime.CompositionImpl.composeInitial(Composition.kt:649)
at androidx.compose.runtime.CompositionImpl.setContent(Composition.kt:635)
at androidx.compose.ui.window.Application_desktopKt$awaitApplication$2$1$2.invokeSuspend(Application.desktop.kt:221)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
To Reproduce Steps to reproduce the behavior:
- Start the app on Fedora 40 twice
Expected behavior The app not to crash on startup of course
Screenshots
I've enabled the following permissions of the flatpak using the Flatseal app:
Desktop
- OS: Fedora 40 KDE
- Version of the app: 1.4.0
Hello!
That's weird! I'm on archlinux with Wayland and works nicely. I'll try to spin up a VM and test it. I'll give you some feedback in a few days.
Hello,
Sorry for the late response. I've tried to run the flatpak version and it worked without issues, however, the jar has shown the exact same error you have described, I'll see what I can do about it.
Ok I managed to get some progress.
It seems that the issue was that, on Wayland, the software would try to connect to X11 display first.
By disabling socket=x11 and socket=wayland, then leaving socket=fallback-x11 enabled, the user interface starts.
However, after about 30 seconds the application closes on its own (no bug shown). Terminal output:
~$ flatpak run com.jetpackduba.Gitnuro
[LOG] OS - OS is linux
log4j:WARN No appenders could be found for logger (org.slf4j).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
[LOG] ShellManager - runCommand: which zenity 2>/dev/null
2024-11-15 11:07:16 INFO slf4j:10 - ShellManager - runCommand: which zenity 2>/dev/null
[LOG] SystemDialogs - IsZenityInstalled true
2024-11-15 11:07:16 INFO slf4j:10 - SystemDialogs - IsZenityInstalled true
[LOG] ShellManager - runCommand: zenity --file-selection --title=Open --directory
2024-11-15 11:07:16 INFO slf4j:10 - ShellManager - runCommand: zenity --file-selection --title=Open --directory
Maybe it has to do with KDE, I'll try running it on another desktop.
Running with java -jar Gitnuro-linux-x86_64-1.4.2.jar (so, not from Flatpak) works perfectly
Does it happen when trying to open a folder or it crashes after a while without doing anything in specific? Is your flatpak package updated? I addressed a bug related to a crash in the last release.
Happens without doing anything, too.
I have installed the latest version of both the flatpak and jar versions.
Il ven 15 nov 2024, 11:51 Abdelilah El Aissaoui @.***> ha scritto:
Does it happen when trying to open a folder or it crashes after a while without doing anything in specific? Is your flatpak package updated? I addressed a bug related to a crash in the last release.
— Reply to this email directly, view it on GitHub https://github.com/JetpackDuba/Gitnuro/issues/241#issuecomment-2478548282, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMONLPXUPKGXKOSJEC3AT32AXG4XAVCNFSM6AAAAABPUPOXQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZYGU2DQMRYGI . You are receiving this because you authored the thread.Message ID: @.***>
Could you try v1.4.1?
If no error is shown, it seems like something went wrong out of the JVM. The only 2 parts using native code are the directory watch and the SSH auth. 1.4.1 had a bug where the directory watch wasn't started, so it would help to reduce the possibilities.