Race situation inside Fiji, Pet Ct viewer

fiji
imagej

#1

Because of extra icons appearing the the Windows OS, it is convenient for most users of Pet Ct viewer to hide the original ImageJ image windows. In the Pet Ct viewer, View menu, there is a check box for Show source where the user can display or hide the original data. Most users hide the data, but he is free to change his choice at any time.

If he chooses to hide the source data, when he closes the study, the source data windows are closed as well. So the Pet Ct window first gives commands to close the source data and then it closes itself.
In the ImageJ Window menu there is a list of open windows. The source windows appear in this list irrespective if they are hidden or not (good idea, don’t change).

The problem is there seems to be a race such that 20-30% of the time ImageJ will report an inconsistency between the actual open windows and the windows listed in the Window menu. I put a short sleep in my program after giving the command to close the windows such that ImageJ would have time to sort out things. The sleep helps nothing, probably because of the thread where it is running.

In any case you can see from the error list that the problem is not connected to my program, most likely because my program is already closed. All the errors are at the ImageJ level. If there are any ideas what might be causing the problem I would be happy to test the daily build to see if anything has improved.

It isn’t a show stopper problem, but it is still annoying.

java.lang.ArrayIndexOutOfBoundsException: 1 >= 1
at java.util.Vector.removeElementAt(Vector.java:561)
at ij.WindowManager.removeImageWindow(WindowManager.java:378)
at ij.WindowManager.removeWindow(WindowManager.java:357)
at ij.WindowManager.removeWindow(WindowManager.java:371)
at ij.gui.ImageWindow.close(ImageWindow.java:420)
at ij.gui.StackWindow.close(StackWindow.java:192)
at ij.ImagePlus.close(ImagePlus.java:389)
at ij.plugin.Commands.closeImage(Commands.java:138)
at ij.plugin.Commands.close(Commands.java:91)
at ij.plugin.Commands.run(Commands.java:29)
at ij.IJ.runPlugIn(IJ.java:199)
at ij.Executer.runCommand(Executer.java:137)

Thanks,
Ilan


#2

Hi Ilan,
The latest daily build (1.52m5) adds a check to verify that the index that causes this exception is within range and it displays debugging information in the Log window if it is out of range. Please test the daily build and report what you find.


#3

Thanks Wayne for the VERY prompt response.

The problem is still there

(Fiji Is Just) ImageJ 2.0.0-rc-69/1.52m5; Java 1.8.0_172 [64-bit]; Linux 4.15.0-45-generic; 555MB of 7472MB (7%)

java.lang.ArrayIndexOutOfBoundsException: 1 >= 1
at java.util.Vector.removeElementAt(Vector.java:561)
at ij.WindowManager.removeImageWindow(WindowManager.java:379)
at ij.WindowManager.removeWindow(WindowManager.java:357)
at ij.WindowManager.removeWindow(WindowManager.java:371)
at ij.gui.ImageWindow.close(ImageWindow.java:420)
at ij.gui.StackWindow.close(StackWindow.java:192)
at ij.ImagePlus.close(ImagePlus.java:389)
at ij.plugin.Commands.closeImage(Commands.java:138)
at ij.plugin.Commands.close(Commands.java:91)
at ij.plugin.Commands.run(Commands.java:29)
at ij.IJ.runPlugIn(IJ.java:199)
at ij.Executer.runCommand(Executer.java:137)

It still occurs at the same low frequency. With the new daily build in some sense it is slightly worse. I saw a case where there were 3 log windows, one for each “miss”. I tried to duplicate the multiple log windows, but the frequency of the problem is low enough that I ran out of patience. The above case is only a single log window.

Most of the time everybody wins the race, but from time to time somebody loses. I don’t see any obvious change in the frequency.

Thanks for your help,
Ilan


#4

Today’s daily build (1.52m6) puts the WindowManager.removeImageWindow() method in a try/catch clause, which should prevent this exception form occurring.