Open Yang-J-LIN opened 2 years ago
@Yang-J-LIN Ah, that is unfortunate. Have you seen the relevant troubleshooting instructions? https://imagej.net/learn/troubleshooting#if-imagej-freezes-or-hangs
In particular, try shift+\ from the main Fiji window to see if you can capture a thread dump. Then we will at least learn where it's hanging, if not why.
@ctrueden Hi, thanks for the quick reply. The easy way does not work. So I tried the "fallback" way. Here is the message after I pressed "export":
[DEBUG] Selected 'net.imagej.ops.Ops$Create$Img' op: net.imagej.ops.create.img.CreateImgFromII [DEBUG] Selected 'net.imagej.ops.Ops$Create$Img/net.imagej.ops.special.function.UnaryFunctionOp' op: net.imagej.ops.create.img.CreateImgFromDimsAndType [DEBUG] Selected 'net.imagej.ops.Ops$Create$ImgFactory' op: net.imagej.ops.create.imgFactory.DefaultCreateImgFactory [DEBUG] Selected 'net.imagej.ops.copy.CopyRAI' op: net.imagej.ops.copy.CopyRAI [DEBUG] Selected 'net.imagej.ops.Ops$Copy$Type/net.imagej.ops.special.computer.UnaryComputerOp' op: net.imagej.ops.copy.CopyType [DEBUG] Selected 'net.imagej.ops.Ops$Map/net.imagej.ops.special.computer.UnaryComputerOp' op: net.imagej.ops.map.MapUnaryComputers$IIToRAIParallel [DEBUG] Selected 'net.imagej.ops.Ops$Create$Img/net.imagej.ops.special.function.UnaryFunctionOp' op: net.imagej.ops.create.img.CreateImgFromDimsAndType [DEBUG] Selected 'net.imagej.ops.Ops$Create$ImgFactory' op: net.imagej.ops.create.imgFactory.DefaultCreateImgFactory [DEBUG] Selected 'net.imagej.ops.thread.chunker.ChunkerOp' op: net.imagej.ops.thread.chunker.DefaultChunker [DEBUG] Selected 'net.imagej.ops.Ops$Stats$Max' op: net.imagej.ops.stats.IterableMax [DEBUG] publish( context = org.scijava.Context@1eac852e consumed = false object =
,null,null), called from non-EDT Thread:null [DEBUG] publish( context = org.scijava.Context@1eac852e consumed = false items[0] = ,null,null), called from non-EDT Thread:null [DEBUG] publish( context = org.scijava.Context@1eac852e consumed = false view = net.imagej.display.DefaultDatasetView@84fc3ea,null,null), called from non-EDT Thread:null [DEBUG] publish( context = org.scijava.Context@1eac852e consumed = false object = Intensity,null,null), called from non-EDT Thread:null [DEBUG] publish( context = org.scijava.Context@1eac852e consumed = false items[0] = Intensity,null,null), called from non-EDT Thread:null [DEBUG] publish( context = org.scijava.Context@1eac852e consumed = false display = Intensity,null,null), called from non-EDT Thread:null
Btw, there is also a warning message when I open the FlimJ, I do not know whether it will affect this:
Apr 21, 2022 8:32:22 PM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 11.0.1 by JavaFX runtime of version 8.0.322 Apr 21, 2022 8:32:22 PM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 11.0.1 by JavaFX runtime of version 8.0.322 Apr 21, 2022 8:32:22 PM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 11.0.1 by JavaFX runtime of version 8.0.322 Apr 21, 2022 8:32:23 PM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 11.0.1 by JavaFX runtime of version 8.0.322 Apr 21, 2022 8:32:23 PM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 11.0.1 by JavaFX runtime of version 8.0.322 Apr 21, 2022 8:32:23 PM javafx.fxml.FXMLLoader$ValueElement processValue WARNING: Loading FXML document with JavaFX API of version 11.0.1 by JavaFX runtime of version 8.0.322
@Yang-J-LIN So with your terminal open and in focus, pressing ctrl+\ (or Ctrl+Pause on Windows) did not print a thread dump? I am not seeing such a thing in the output you included. Normally it would look something like this:
^\2022-04-21 15:32:13
Full thread dump OpenJDK 64-Bit Server VM (25.322-b06 mixed mode):
"DestroyJavaVM" #26 prio=5 os_prio=31 tid=0x00007f78b4008800 nid=0xc07 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"MarlinRenderer Disposer" #25 daemon prio=10 os_prio=31 tid=0x00007f78b562c000 nid=0x10f3b in Object.wait() [0x000070000ab76000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
... lots of lines cut here for brevity ...
JNI global references: 4493
Heap
PSYoungGen total 228352K, used 194972K [0x0000000714100000, 0x000000072c180000, 0x00000007c0000000)
eden space 202752K, 96% used [0x0000000714100000,0x000000071ff67200,0x0000000720700000)
from space 25600K, 0% used [0x0000000720700000,0x0000000720700000,0x0000000722000000)
to space 29184K, 0% used [0x000000072a500000,0x000000072a500000,0x000000072c180000)
ParOldGen total 154624K, used 19024K [0x00000005bc200000, 0x00000005c5900000, 0x0000000714100000)
object space 154624K, 12% used [0x00000005bc200000,0x00000005bd494118,0x00000005c5900000)
Metaspace used 53006K, capacity 54335K, committed 54656K, reserved 1095680K
class space used 7273K, capacity 7752K, committed 7808K, reserved 1048576K
The most important bits will be any paragraphs with flimlib.flimj
in one or more lines.
Anyway, I am guessing this problem is related to #25. It's only on macOS, and I think it's something to do with the version of JavaFX included with the Zulu 8 JDK+FX. I vaguely recall we observed this problem before when testing, maybe with the JBRSDK8 as well, which is frustrating. It may be that updating to OpenJDK 11 fixes the issue, but that might necessitate some code changes here to update the JavaFX usage from 8 to 11, as well as introducing dependencies on the now-external JavaFX11 libraries.
I wish I had time to test on my system, since I do also run macOS, and am likely to be able to reproduce these issues, but I am really swamped with I2K workshop preparation at the moment. One other thing to try in the short term might be running Fiji with a different version of Java, perhaps Oracle Java 8 since it includes a copy of JavaFX 8.
@ctrueden Sorry I forget to ctrl
+ \
. I tried to use Oracle Java 8 but it did not work either. I do not know whether it is Mac's problem or the M1 chip's problem.
This is what it prints:
Thanks @Yang-J-LIN, that is very helpful!
Technically speaking, the problem is here:
"JavaFX Application Thread" #10 daemon prio=5 os_prio=31 tid=0x00007f814189d800 nid=0x103 in Object.wait() [0x000000030e11e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1343)
- locked <0x00000006500f4708> (a java.awt.EventQueue$1AWTInvocationLock)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1324)
at org.scijava.thread.DefaultThreadService.invoke(DefaultThreadService.java:115)
at org.scijava.event.DefaultEventBus.publishNow(DefaultEventBus.java:182)
at org.scijava.event.DefaultEventBus.publishNow(DefaultEventBus.java:73)
at org.scijava.event.DefaultEventService.publish(DefaultEventService.java:102)
at org.scijava.display.DefaultDisplayService.createDisplay(DefaultDisplayService.java:213)
at org.scijava.ui.AbstractUserInterface.show(AbstractUserInterface.java:98)
at org.scijava.ui.DefaultUIService.show(DefaultUIService.java:241)
at flimlib.flimj.ui.controller.ExportCtrl.lambda$initialize$2(ExportCtrl.java:83)
at flimlib.flimj.ui.controller.ExportCtrl$$Lambda$353/163044220.handle(Unknown Source)
"AWT-EventQueue-0" #15 prio=6 os_prio=31 tid=0x00007f8140123000 nid=0xd97b runnable [0x000000030fc8b000]
java.lang.Thread.State: RUNNABLE
at sun.awt.CGraphicsDevice.nativeGetScreenInsets(Native Method)
at sun.awt.CGraphicsDevice.getScreenInsets(CGraphicsDevice.java:128)
at sun.lwawt.macosx.LWCToolkit.getScreenInsets(LWCToolkit.java:407)
at java.awt.Window.init(Window.java:506)
at java.awt.Window.<init>(Window.java:537)
at java.awt.Frame.<init>(Frame.java:420)
at ij.gui.ImageWindow.<init>(ImageWindow.java:70)
at ij.gui.ImageWindow.<init>(ImageWindow.java:66)
at ij.ImagePlus.show(ImagePlus.java:507)
at ij.ImagePlus.show(ImagePlus.java:479)
at net.imagej.legacy.display.LegacyImageDisplayViewer.view(LegacyImageDisplayViewer.java:141)
at net.imagej.legacy.display.LegacyImageDisplayViewer.view(LegacyImageDisplayViewer.java:107)
at net.imagej.legacy.ui.LegacyUI$1.run(LegacyUI.java:195)
at org.scijava.thread.DefaultThreadService.invoke(DefaultThreadService.java:111)
at net.imagej.legacy.ui.LegacyUI.show(LegacyUI.java:191)
at org.scijava.ui.DefaultUIService.onEvent(DefaultUIService.java:379)
Or in a nutshell: sun.awt.CGraphicsDevice.nativeGetScreenInsets
hangs the Java GUI subsystem.
I do believe we encountered this problem before with the JetBrains JBRSDK, and there is a bug in their bug tracker about it which has since been fixed. It is unfortunate that the Zulu JDK also suffers from this issue. I did find one other report of this problem with OpenJDK 13 (not sure which flavor), but no answer on that thread about how to fix it.
So, for the moment my advice is still to try with Oracle Java 8. I'd also like to update FLIMJ to JavaFX 11 so that we can test with Zulu 11, 17, and/or 18, but I don't have time right now, unfortunately.
When I try to export the lifetime image, the UI freezes without giving any error information.
I am using the latest version of FIJI (MacOS x86_64), where
zulu8.60.0.21-ca-fx-jdk8.0.322-macosx_x64
is bundled.