Fiji launch failure on linux x64 #50

hinerm · 2024-05-21T15:53:56Z

On a Windows 11 host, I have Ubuntu 24.04 installed via WSL2. There I installed Java with sudo apt-get install openjdk-8-jdk, which gave me a Java 1.8.0_402.

When I launch Fiji with jaunch + this JDK, it gets stuck at Launching user interface:

You can see that there a second splash screen is showing at this point (or maybe the first one just changed as the flat laf takes over) as there are two progress bars and two "Fiji"'s, one slightly inset to the other.

My Jaunch startup debug is:

[DEBUG] Input arguments processed:
[DEBUG] * hints -> [OS:LINUX, ARCH:X64, --debug]
[DEBUG] * vars -> {app-dir=/home/hinerm/Fiji.app, config-dir=/home/hinerm/Fiji.app/config/jaunch, executable=/home/hinerm/Fiji.app/fiji-linux-x64}
[DEBUG] * userArgs.runtime -> []
[DEBUG] * userArgs.main -> []
[DEBUG] * userArgs.ambiguous -> []
[DEBUG]
[DEBUG] Modes applied:
[DEBUG] * hints -> [OS:LINUX, ARCH:X64, --debug, LAUNCH:JVM]
[DEBUG]
[DEBUG] /--------------------------\
[DEBUG] | CONFIGURING RUNTIME: JVM |
[DEBUG] \--------------------------/
[DEBUG]
[DEBUG] Root paths to search for Java:
[DEBUG] * /usr/lib/jvm/java-1.8.0-openjdk-amd64
[DEBUG] * /home/hinerm/Fiji.app/java/linux-amd64/zulu8.60.0.21-ca-fx-jdk8.0.322-linux_x64
[DEBUG] * /usr/lib/jvm/java-8-openjdk-amd64
[DEBUG]
[DEBUG] Suffixes to check for libjvm:
[DEBUG] * lib/server/libjvm.so
[DEBUG] * jre/lib/amd64/server/libjvm.so
[DEBUG] * lib/server/libjvm.so
[DEBUG] * jre/lib/amd64/server/libjvm.so
[DEBUG] * lib/server/libjvm.so
[DEBUG] * jre/lib/amd64/server/libjvm.so
[DEBUG]
[DEBUG] Discovering Java installations...
[DEBUG] Analyzing candidate JVM directory: '/usr/lib/jvm/java-1.8.0-openjdk-amd64'
[DEBUG] Guessing OS name...
[DEBUG] Reading release file...
[DEBUG] Invoking `"/usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java" Props`...
[DEBUG] -> OS name: LINUX
[DEBUG] Guessing CPU architecture...
[DEBUG] -> CPU architecture: X64
[DEBUG] Guessing Java version...
[DEBUG] * rootString -> java-1.8.0-openjdk-
[DEBUG] * versions8u -> []
[DEBUG] * versionsPrefixed -> [1.8.0]
[DEBUG] -> Java version: 1.8.0
[DEBUG] Successfully discovered Java installation:
[DEBUG] * rootPath -> /usr/lib/jvm/java-1.8.0-openjdk-amd64
[DEBUG] * libjvmPath -> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
[DEBUG] * binJava -> /usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java
[DEBUG] * hints -> [OS:LINUX, ARCH:X64, --debug, LAUNCH:JVM, JAVA:8, JAVA:0+, JAVA:1+, JAVA:2+, JAVA:3+, JAVA:4+, JAVA:5+, JAVA:6+, JAVA:7+, JAVA:8+]
[DEBUG]
[DEBUG] Classpath to calculate:
[DEBUG] * /home/hinerm/Fiji.app/jars/imagej-launcher*.jar
[DEBUG]
[DEBUG] Classpath calculated:
[DEBUG] * /home/hinerm/Fiji.app/jars/imagej-launcher-6.0.2.jar
[DEBUG]
[DEBUG] JVM arguments calculated:
[DEBUG] * -Dij.debug=true
[DEBUG] * -Dscijava.log.level=debug
[DEBUG] * -XX:+UseG1GC
[DEBUG] * -Dpython.cachedir.skip=true
[DEBUG] * -Dplugins.dir=/home/hinerm/Fiji.app
[DEBUG] * -Dimagej.splash=true
[DEBUG] * -Dimagej.dir=/home/hinerm/Fiji.app
[DEBUG] * -Dij.dir=/home/hinerm/Fiji.app
[DEBUG] * -Dfiji.dir=/home/hinerm/Fiji.app
[DEBUG] * -Dfiji.executable=/home/hinerm/Fiji.app/fiji-linux-x64
[DEBUG] * -Dij.executable=/home/hinerm/Fiji.app/fiji-linux-x64
[DEBUG] * -Djava.library.path=/home/hinerm/Fiji.app/lib/linux64
[DEBUG] * -Dscijava.context.strict=false
[DEBUG] * -Dpython.console.encoding=UTF-8
[DEBUG] Added classpath arg: -Djava.class.path=/home/hinerm/Fiji.app/jars/imagej-launcher-6.0.2.jar
[DEBUG]
[DEBUG] Calculating max heap (75%)...
[DEBUG] System reported memTotal of 12469739520
[DEBUG] Added maxHeap arg: -Xmx8919m
[DEBUG]
[DEBUG] Calculating main class name...
[DEBUG] mainProgram -> net.imagej.launcher.ClassLauncher
[DEBUG]
[DEBUG] Main arguments calculated:
[DEBUG] * -ijjarpath
[DEBUG] * jars
[DEBUG] * -ijjarpath
[DEBUG] * plugins
[DEBUG] * net.imagej.Main

Our Fiji distros have a bundled zulu8.60.0.21-ca-fx-jdk8.0.322-linux_x64 JDK and when I unset JAVA_HOME and point to this bundled Java, Fiji starts no problem.

I tested on Windows with another 1.8.0_422 jdk and had no problem launching.

Current debugging questions:

Does this fail for other WSL2 installations?
Does this fail on non-WSL linux installations?

The text was updated successfully, but these errors were encountered:

ctrueden · 2024-05-21T17:35:43Z

Two more questions:

If you use --dry-run and then replicate the outputted command with that same java (i.e. take jaunch out of the equation), does it still hang?
What is the full thread dump after the hang?

hinerm · 2024-05-21T18:48:27Z

Does this fail for other WSL2 installations?

It looks like this doesn't fail. On a different windows host with Ubuntu 22.04 WSL2, we did a slightly different process in that --java-home was used, but still openjdk 1.8.0_402. Worked no problem.

If you use --dry-run and then replicate the outputted command with that same java (i.e. take jaunch out of the equation), does it still hang?

It does still hang!

What is the full thread dump after the hang?

Looks like flat laf is doing GUI stuff off the EDT?

"AWT-EventQueue-1" #18 prio=6 os_prio=0 tid=0x00005645ab414000 nid=0x254 waiting for monitor entry [0x00007f90641d7000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.awt.Component.invalidate(Component.java:2934)
        - waiting to lock <0x000000059289dc60> (a java.awt.Component$AWTTreeLock)
        at java.awt.Container.invalidate(Container.java:1590)
        at javax.swing.JComponent.revalidate(JComponent.java:4848)
        at javax.swing.JComponent.lambda$revalidate$0(JComponent.java:4860)
        at javax.swing.JComponent$$Lambda$57/2097989776.run(Unknown Source)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
        at java.awt.EventQueue.access$500(EventQueue.java:97)
        at java.awt.EventQueue$3.run(EventQueue.java:709)
        at java.awt.EventQueue$3.run(EventQueue.java:703)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
        at java.awt.EventQueue$4.run(EventQueue.java:733)
        at java.awt.EventQueue$4.run(EventQueue.java:731)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
        at org.GNOME.Accessibility.AtkWrapper$6.dispatchEvent(AtkWrapper.java:717)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

"main" #1 prio=5 os_prio=0 tid=0x00005645aafaa800 nid=0x205 waiting on condition [0x00007ffd1ab11000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x000000059a09b228> (a java.util.concurrent.FutureTask)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
        at java.util.concurrent.FutureTask.get(FutureTask.java:191)
        at org.GNOME.Accessibility.AtkUtil.invokeInSwing(AtkUtil.java:68)
        at org.GNOME.Accessibility.AtkObject.hashCode(AtkObject.java:234)
        at org.GNOME.Accessibility.AtkWrapper.emitSignal(Native Method)
        at org.GNOME.Accessibility.AtkWrapper$5.propertyChange(AtkWrapper.java:557)
        at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335)
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327)
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263)
        at javax.accessibility.AccessibleContext.firePropertyChange(AccessibleContext.java:768)
        at javax.swing.JScrollPane$AccessibleJScrollPane.stateChanged(JScrollPane.java:1506)
        at javax.swing.JViewport.fireStateChanged(JViewport.java:1369)
        at javax.swing.JViewport.reshape(JViewport.java:839)
        at java.awt.Component.setBounds(Component.java:2261)
        at java.awt.Component.setBounds(Component.java:2405)
        at javax.swing.ScrollPaneLayout.layoutContainer(ScrollPaneLayout.java:890)
        at com.formdev.flatlaf.ui.FlatScrollPaneUI$FlatScrollPaneLayout.layoutContainer(FlatScrollPaneUI.java:562)
        at java.awt.Container.layout(Container.java:1513)
        at java.awt.Container.doLayout(Container.java:1502)
        at java.awt.Container.validateTree(Container.java:1698)
        at java.awt.Container.validateTree(Container.java:1707)
        at java.awt.Container.validateTree(Container.java:1707)
        at java.awt.Container.validateTree(Container.java:1707)
        at java.awt.Container.validateTree(Container.java:1707)
        at java.awt.Container.validate(Container.java:1633)
        - locked <0x000000059289dc60> (a java.awt.Component$AWTTreeLock)
        at javax.swing.SwingUtilities.updateComponentTreeUI(SwingUtilities.java:1231)
        at com.formdev.flatlaf.FlatLaf.updateUI(FlatLaf.java:1051)
        at org.scijava.ui.swing.laf.SwingLookAndFeelService.setLookAndFeel(SwingLookAndFeelService.java:144)
        at org.scijava.ui.swing.laf.SwingLookAndFeelService.initLookAndFeel(SwingLookAndFeelService.java:91)
        at net.imagej.legacy.IJ1Helper.setVisible(IJ1Helper.java:326)
        at net.imagej.legacy.ui.LegacyUI.show(LegacyUI.java:132)
        at org.scijava.ui.DefaultUIService.showUI(DefaultUIService.java:164)
        at org.scijava.ui.DefaultUIService.showUI(DefaultUIService.java:149)
        at org.scijava.AbstractGateway.launch(AbstractGateway.java:111)
        at net.imagej.Main.main(Main.java:53)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at net.imagej.launcher.ClassLauncher.launch(ClassLauncher.java:279)
        at net.imagej.launcher.ClassLauncher.run(ClassLauncher.java:186)
        at net.imagej.launcher.ClassLauncher.main(ClassLauncher.java:87)

To avoid potential deadlocks such as the one described at apposed/jaunch#50 (comment)

ctrueden · 2024-05-21T20:23:50Z

@hinerm For when we revisit this issue later, I pushed a branch set-laf-on-edt which you can try on your affected local installation.

ctrueden added a commit to scijava/scijava-ui-swing that referenced this issue May 21, 2024

Set the Look & Feel on the EDT

78eb1f5

To avoid potential deadlocks such as the one described at apposed/jaunch#50 (comment)

ctrueden added a commit to scijava/scijava-ui-swing that referenced this issue May 21, 2024

Set the Look & Feel on the EDT

e4c3f4f

To avoid potential deadlocks such as the one described at apposed/jaunch#50 (comment)

ctrueden added app:fiji bug Something isn't working labels Aug 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fiji launch failure on linux x64 #50

Fiji launch failure on linux x64 #50

hinerm commented May 21, 2024 •

edited

Loading

ctrueden commented May 21, 2024 •

edited

Loading

hinerm commented May 21, 2024

ctrueden commented May 21, 2024

Fiji launch failure on linux x64 #50

Fiji launch failure on linux x64 #50

Comments

hinerm commented May 21, 2024 • edited Loading

ctrueden commented May 21, 2024 • edited Loading

hinerm commented May 21, 2024

ctrueden commented May 21, 2024

hinerm commented May 21, 2024 •

edited

Loading

ctrueden commented May 21, 2024 •

edited

Loading