Hello everyone. I am desperate as I have this prob...
# compose-desktop
d
Hello everyone. I am desperate as I have this problem for quite a long time and fail to find an appropriate solution. I am trying to open an AWT FileDialog inside Compose for Desktop. However, this makes the JVM crash. I already created a ticket in August but nobody interacted. I now created a reproduction repository: https://github.com/ptitjes/repro-compose-issue-2249 It contains two main files: • Main.kt, launches an AWT FileDialog through Compose integration (and fails) • MainAwt.kt, launchs an AWT FileDialog directly (and succeeds) Details of the Compose code, log, JVM crash log and execution platform in the thread.
The Compose code:
Copy code
fun main() = application {
    Window(onCloseRequest = ::exitApplication) {
        App(window)
    }
}

@Composable
@Preview
fun App(window: ComposeWindow) {
    var open by remember { mutableStateOf(false) }
    var result by remember { mutableStateOf<String?>(null) }

    Column {
        Button(
            onClick = { open = true }
        ) {
            Text("Open")
        }

        Text("Result: $result")
    }

    if (open) {
        AwtWindow(
            create = {
                object : FileDialog(window, "Select a file", LOAD) {
                    override fun setVisible(value: Boolean) {
                        super.setVisible(value)
                        if (value) {
                            result = file
                            open = false
                        }
                    }
                }
            }, dispose = FileDialog::dispose
        )
    }
}
The log in console:
Copy code
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f06ef7736c7, pid=271663, tid=271752
#
# JRE version: OpenJDK Runtime Environment (Red_Hat-17.0.5.0.8-1.fc37) (17.0.5+8) (build 17.0.5+8)
# Java VM: OpenJDK 64-Bit Server VM (Red_Hat-17.0.5.0.8-1.fc37) (17.0.5+8, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libcairo.so.2+0x976c7]
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to /home/didier/Code/Didier/test-compose-awt-filedialog/core.271663)
#
# An error report file with more information is saved as:
# /home/didier/Code/Didier/test-compose-awt-filedialog/hs_err_pid271663.log
#
# If you would like to submit a bug report, please visit:
#   <https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=java-17-openjdk&version=37>
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
The JVM crash log: https://github.com/ptitjes/repro-compose-issue-2249/blob/main/hs_err_pid271663.log
Details of my execution platform: Linux Fedora 37 Gnome 43.2 Wayland Kernel 6.0.17-300.fc37.x86_64
s
d
@Stefan Oltmann Nope, did not. But the way documented by JB on the compose-jb repository is supposed to work isn't it ? (cf. https://github.com/JetBrains/compose-jb/tree/master/tutorials/Window_API_new#swing-interoperability)
s
Sure, you reported it already as bug that it does not work. So this is for now not an option. If you need a file chooser you could either use the Swing one (which works) or try the mentioned framework which also provides a native file chooser.
d
@Stefan Oltmann I just tried using
compose-multiplatform-file-picker
and I get the exact same crash with Cairo...
s
In that case you should go with a Swing implementation until the problem gets fixed.
d
I was trying to avoid that... I despise Swing's look and feel, whereas native AWT dialogs looks great on Linux.
a
This is a crash from a lib shipped with the system so it doesn't look like something that can be fixed on the compose side (or even JVM side) and I suggest you report it to Fedora.
s
I find the Swing FileChooser looks okay after setting system look and feel.
Copy code
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName())
d
Huh, never knew this trick. I will try that, thanks.
@Albert Chang I am not that sure. Indeed, as explain in the main message, launching directly the AWT dialog without any Compose works!! See in the reproduction repository the second main file
MainAwt.kt
which does:
Copy code
fun main() {
    val frame = Frame("Window")
    val dialog = FileDialog(frame, "Select a file", LOAD)
    dialog.isVisible = true
}
This code works with the same JVM, OS, etc.
a
So what? Just because compose is probably using another API doesn't mean it's compose to blame. The error message clearly shows that the crash came from libcairo.
k
Doesn’t look like you’re using the AWT file dialog though
Copy code
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libcairo.so.2+0x976c7]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.util.nfd.NativeFileDialog.nNFD_OpenDialog(JJJ)I+0
j  org.lwjgl.util.nfd.NativeFileDialog.NFD_OpenDialog(Ljava/lang/CharSequence;Ljava/lang/CharSequence;Lorg/lwjgl/PointerBuffer;)I+71
j  com.darkrockstudios.libraries.mpfilepicker.FileChooser$chooseFileNative$2.invokeSuspend(Ljava/lang/Object;)Ljava/lang/Object;+87
d
I am not saying that it does come from Compose, but that there is a great chance. Did you take a look at the two main files? I use the exact same AWT APIs, first inside Compose/Swing integration and second directly. Compose for Desktop does some initialization of Swing. At some point, adding ``-Dcompose.application.configure.swing.globals=false` disabled the initialization and the bug. I can't tell since which version, but at least with the
1.2
version of Compose, this workaround does not work.
k
Are you using the LWJGL file dialog?
d
@Kirill Grouchnikov Please look at the original crash file. The latest one was to try @Stefan Oltmann's suggestion.
k
Looks like what is common is that in both cases, the dialog is opened off the main thread
d
Should I do something more in my use of
AwtWindow
to make the dialog open in the UI thread? (cf. code at the begining of the slack thread)
a
You are using the API directly and through compose, which can be different, especially the setup under the hood. Since compose doesn't interact directly with libcairo, I have no idea how it can cause a segmentation fault inside libcairo. I also don't understand why you seem reluctant to report this to Fedora.
d
Well, before that, I'll try on an Ubuntu tomorrow.
Also, they will surely have a similar (but opposite) reaction te yours. If I don't have more informations, they will surely blame Compose, because it works outside of Compose.
a
Aside from the reported issue, if you are interested in using native file pickers on linux, I'd try using zenity
s
I just tried it on Ubuntu 22.04, no problems.
a
Trust me, they are experts and they know how to read crash reports 😉 so be sure to include the core dump.
n
I am not that sure. Indeed, as explained in the main message, launching directly the AWT dialog without any Compose works!!
I believe you can reproduce the issue with pure AWT code. What if you wrap your AWT code with invokeLater(), like: fun main() { SwingUtilities.invokeLater { val frame = Frame("Window") val dialog = FileDialog(frame, "Select a file", LOAD) SwingUtilities.invokeLater { dialog.isVisible = true } } }
a
this might be related to the crash I just logged: https://github.com/JetBrains/compose-jb/issues/2624
n
this might be related to the crash
unlikely
d
@Nikita Lipsky I added a new
MainAwtLater.kt
with your suggestion to the reproduction repository (cf. start of the Slack thread). It doesn't crash on Fedora.
n
Then maybe we need more complex example with AWT ….
d
@Ed Brindley and @Sean Proctor, would you mind to tell me if your distributions use X11 or Wayland?
e
I'm still using X11 on this machine. I do have a laptop where I use Arch and Wayland, so I can try it on there if that would be useful.
d
@Ed Brindley well I now believe this will exhibit the failure.
e
@Didier Villevalois Also working on Arch / Gnome / Wayland
d
Well, thanks @Ed Brindley for the time you took to test. Still can't see what the problem is...