Thanks Ilan, this is a known issue, and fixing it is one of our top priorities over the next few days.

I will work on fixing this over the next day or two.

*** Bug 822 has been marked as a duplicate of this bug. ***

First cut at a fix:

https://github.com/imagej/ij1-patcher/compare/close-all-windows
https://github.com/imagej/imagej-legacy/compare/fiji-wont-quit

Still needs manual testing as well as regression tests. Barring any critical flaws in the approach, we can hopefully finish resolving this problem by end of Monday.

We have now released and uploaded the quit-related fixes! Can you please test, and reopen this bug if the issue is not resolved?

I just went to update Fiji, and I noticed that the button which usually says "Apply changes" now says "Apply changes (upload)". When I clicked it, I got the following errors:

Exception in thread "Thread-7" java.lang.RuntimeException: Missing upload information for site http://update.imagej.net/
	at net.imagej.updater.UpdateSite.getUploadProtocol(UpdateSite.java:186)
	at net.imagej.updater.FilesUploader.<init>(FilesUploader.java:126)
	at net.imagej.ui.swing.updater.UpdaterFrame.upload(UpdaterFrame.java:799)
	at net.imagej.ui.swing.updater.UpdaterFrame$5$1.run(UpdaterFrame.java:311)

Thanks.

Hi Curtis,
I updated this morning to ImageJ 1.49c and the situation is horrible. Even Fiji won't die. I have to go into System monitor in order to kill it. I'm on a Linux 32 bit machine. I'll continue to check.

Thanks,
Ilan

Hi Curtis,
I have some more details for you. On my Linux machine if I leave an Image stack open, then Fiji won't close. A couple of versions ago closing Fiji would close all open images. Now it just hangs.
The situation is also bad on the Mac. Apparently when I close my Pet-Ct Viewer some daughter process is still alive. Closing Fiji on the Mac makes all the visible windows go away but Activity Monitor shows that it is still alive. On the Mac Quit isn't enough - you need Force Quit.
Since this is my program I have to find out what daughter process is still alive and kill it. It used to be that closing Fiji would kill everything so I never knew a problem existed.

On Linux I don't need any Force Quit but I can see that Pet-Ct Viewer still has something hanging around. I need to find out what is still alive from my program.

In addition, on Linux, even if I never activate Pet-Ct Viewer, but I leave an Image open, Fiji will simply refuse to close and all windows remain visible.

So, in the meantime, let me see what part of the mess Pet-Ct Viewer is contributing.
Ilan

Hi Curtis,
I've been over my programs Pet-Ct Viewer and 3 view. Pet-Ct Viewer is more complicated that it needs to sync up to N instances so that they all shift together.
I saw that if I read Pet and CT data with Pet-Ct Viewer ImageJ won't close. It looks like it is closed but System Monitor shows it is still alive. I looked at what ImageJ was running and the result was "everything". Every process I've ever come across was running inside ImageJ, including my Pet-Ct Viewer. My program was one of hundreds so it was difficult to find.
I saw that even if I ran 3 view, the problem still exists. 3 view is far simpler with just a single pipe to the original data. It seems that as soon as I connect to even a single ImagePlus object, even if I free the object by setting the pipe=null, something or other isn't being freed.
This fits in with the general problem that even if I operate none of my programs, but just close ImageJ with an ImagePlus object open, it crashes. My program which establishes a connection to the ImagePlus object, and then breaks the connection, shows a less serious problem. In this case I "x" out the ImagePlus object but something is remaining such that ImageJ apparently closes but really doesn't close.

Ilan

Ilan, I am sorry that you are still having problems. However, based on your description, I cannot reproduce any of them. You need to be much more precise in how to replicate the issue. Something like this:

"With a fully up-to-date Fiji, with only the ImageJ and Fiji update sites enabled, on Ubuntu 14.04 LTS 32-bit, I see the following behavior:

* Launch Fiji on the command line with ./ImageJ-linux32
* Press Shift+B to open the Blobs sample image
* Run "Quit" from the "File" menu
* Observe that the process does not terminate and return control to the command line"

Please write a description like that so that it is possible for me to reproduce, or else I will not be able to debug the problem.

P.S. You could also try generating a stack trace to glean more information about why Fiji isn't quitting: http://fiji.sc/Debugging_intro#Debugging_JVM_hangs

Hi,

I was able to update Fiji, but I still see the problem:

$ /usr/share/Fiji.app/ImageJ-linux64  --java-home '/usr/lib/jvm/java-7-openjdk-amd64'

log4j:WARN No appenders could be found for logger (org.bushe.swing.event.EventService).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
[ERROR] Skipping unsupported option -port7


And when I close Fiji:


Exception during disposal:
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(EventQueue.java:1272)
	at java.awt.Window.doDispose(Window.java:1209)
	at java.awt.Window.dispose(Window.java:1147)
	at ij.ImageJ.run(ImageJ.java:767)
	at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.IllegalArgumentException: null source
	at java.util.EventObject.<init>(EventObject.java:56)
	at java.awt.AWTEvent.<init>(AWTEvent.java:337)
	at java.awt.event.InvocationEvent.<init>(InvocationEvent.java:224)
	at java.awt.event.InvocationEvent.<init>(InvocationEvent.java:188)
	at java.awt.event.InvocationEvent.<init>(InvocationEvent.java:150)
	at sun.awt.X11.XBaseMenuWindow.dispose(XBaseMenuWindow.java:907)
	at java.awt.MenuComponent.removeNotify(MenuComponent.java:310)
	at java.awt.Menu.removeNotify(Menu.java:198)
	at java.awt.Component.removeNotify(Component.java:6980)
	at java.awt.Container.removeNotify(Container.java:2800)
	at java.awt.Window.removeNotify(Window.java:782)
	at java.awt.Frame.removeNotify(Frame.java:1041)
	at java.awt.Window$1DisposeAction.run(Window.java:1190)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:241)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
	at java.awt.EventQueue.access$200(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:694)
	at java.awt.EventQueue$3.run(EventQueue.java:692)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
	at java.awt.EventQueue$4.run(EventQueue.java:708)
	at java.awt.EventQueue$4.run(EventQueue.java:706)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)


Here is the output when I run the bug report form:

Information about your version of Java:

  os.arch => amd64
  os.name => Linux
  os.version => 3.11.0-24-generic
  java.version => 1.7.0_55
  java.vendor => Oracle Corporation
  java.runtime.name => OpenJDK Runtime Environment
  java.runtime.version => 1.7.0_55-b14
  java.vm.name => OpenJDK 64-Bit Server VM
  java.vm.version => 24.51-b03
  java.vm.vendor => Oracle Corporation
  java.vm.info => mixed mode
  java.awt.graphicsenv => sun.awt.X11GraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.7
  sun.cpu.endian => little
  sun.desktop => null
  file.separator => /

The up-to-date check says: REMIND_LATER

Information relevant to JAVA_HOME related problems:

  JAVA_HOME is set to: /usr/lib/jvm/java-7-openjdk-amd64/jre
  imagej.dir => /usr/share/Fiji.app

Information about the version of each plugin:

Activated update sites:
ImageJ: http://update.imagej.net/ (last check:20140701154719)
Fiji: http://fiji.sc/update/ (last check:20140702124334)

Files not up-to-date:
  0d538731 (LOCAL_ONLY) 20140604135013 plugins/PhiDM_Version4_1.class
  e768f18b (LOCAL_ONLY) 20140623155730 plugins/jars/commons-math3-3.3.jar
  bd1f4461 (LOCAL_ONLY) 20140623155740 plugins/jars/jtransforms-2.4.jar

Hi Curtis,
I appreciate your problem. I didn't even know about the blob test image.
With exactly what you suggest I do, I loaded the blob image and without closing it I tried to close Fiji. I got no errors in the terminal but Fiji wouldn't close.
All this I tried on Jerry Kolodny's Mac (so Mac in place of Linux). The real problem with Jerry is he just wants to do his clinical stuff and not be bothered by our nonsense.
He wants to do Pet-Ct. The problem for him is it looks like Fiji is being shut down when it isn't. All the windows go away but in the system monitor it is still clearly running. He can't turn off his computer unless he first does a Force Quit of the phantom Fiji.
At least for the moment I showed him how to Force Quit Fiji. He isn't exactly happy that I updated Fiji and introduced all this mess.

BTW, what is the question about using SCSIO (or some other thing) after an update? I always leave the check, but maybe I should remove it? It seems to be an important question since it comes up after every update.

I'll keep plugging away to see what I can learn from my local Linux machine.
Thanks,
Ilan

Hi Curtis,
I'm still looking at "high level" actions to see if I can find anything. I ran Plugins->Debug->Stack Dump and I didn't see my plugins which were running at the time. It would make eminent sense that if my programs don't appear in the stack dump, Fiji doesn't know that they exist and would therefore not close them.
As per your suggestion I added WindowManager.addWindow(this). This is enough to close the window but it probably isn't enough for Stack Dump to know about the program.
Thus it would make sense that any remnants of the program wouldn't get killed when Fiji dies. This would give the phantom Fiji which I see.

Another symptom of the same problem turns up when I press the menu item Windows. I see a check box but no title for any of my plugins. Apparently the windows manager addWindow is necessary but not sufficient.

Thanks,
Ilan

Hi Curtis,
I didn't realize that SCIFIO was ImageJ2. I need a way to turn it on and off. Jerry couldn't care less about it - he just wants to read the scans and report clinical findings. The fact that he can't turn off the computer without first killing the phantom Fiji is super annoying.
On the other hand, I do want to check out ImageJ2 on Mac. So when Jerry lets me play with his Mac while he is sleeping, I can check out ImageJ2. Then I can turn it off and let him proceed with his normal work without annoyances.
When all is well, we can leave it on.

Thanks,
Ilan

Yes, use of the SCIFIO library is one the things that ImageJ2 brings to the table. However, SCIFIO is not limited to ImageJ2 -- it is a general-purpose scientific multidimensional image I/O library.

You can toggle usage of SCIFIO in the Edit > Options > ImageJ2 dialog. Turning it off should result in ImageJ's file I/O behaving the same as it used to.

However, I am confused why you are mentioning SCIFIO on this issue thread, which is about ImageJ not quitting properly. Is SCIFIO somehow contributing to the not-quitting behavior you observe?

Hi Curtis,
With your answer, now there is a way to check the problem. I certainly want to use the software and find if I have any troubles with it. Together with that I would love to free Jerry from our troubles and let him work in peace.
Of course, until I actually try it, I can't say for sure what the problem is. All he knows is that it used to work OK and why did I make waves?
I also would love to find out what I need to do to have my plugins appear in the list of Windows, with their names, instead of just blank titles. Maybe it is connected and maybe not. I need to try different combinations to see what affects what.
If I discover that I have problems, I will ask all my users not to use SCIFIO until we can figure out what is going on.

Thanks,
Ilan

Hi Curtis,
I just got another shot to try the Mac. I turned off ImageJ2 and the problem is still there. He has to force quit ImageJ in order to power down his computer. This is a real bummer. I left ImageJ2 turned off just to make the problem a bit simpler.
Thanks,
Ilan

Ilan,

 Could you do the following:

1) Run Help > Report a Bug from Fiji
2) Copy the "Useful information about your system" section
3) Paste the copied text here

That will tell us if anything is out of date on the affected systems, or if an update site/plugin is causing problems.



Adam,

 Could you clarify: does your Fiji appear to close (e.g. do the windows disappear) after throwing those exceptions, or do all the windows remain open and it just refuses to close?

If it is the latter case then I think your issue is unrelated to Ilan's and should be in a separate bug report. Regardless, your problems may be from a negative interaction with one of your local plugins, so you could try removing them one at a time to see which, if any, is/are the culprit:

  0d538731 (LOCAL_ONLY) 20140604135013 plugins/PhiDM_Version4_1.class
  e768f18b (LOCAL_ONLY) 20140623155730 plugins/jars/commons-math3-3.3.jar
  bd1f4461 (LOCAL_ONLY) 20140623155740 plugins/jars/jtransforms-2.4.jar

I was finally able to reproduce this in a Windows VM on my system. Investigating now.

Hi Mark,

> Could you clarify: does your Fiji appear to close (e.g. do the windows 
> disappear) after throwing those exceptions, or do all the windows remain 
> open and it just refuses to close?

The former: Fiji appears to close (all windows disappear).

I removed the plugins, and the problem persists. Below is the bug report output.

Information about your version of Java:

  os.arch => amd64
  os.name => Linux
  os.version => 3.11.0-24-generic
  java.version => 1.7.0_55
  java.vendor => Oracle Corporation
  java.runtime.name => OpenJDK Runtime Environment
  java.runtime.version => 1.7.0_55-b14
  java.vm.name => OpenJDK 64-Bit Server VM
  java.vm.version => 24.51-b03
  java.vm.vendor => Oracle Corporation
  java.vm.info => mixed mode
  java.awt.graphicsenv => sun.awt.X11GraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.7
  sun.cpu.endian => little
  sun.desktop => null
  file.separator => /

The up-to-date check says: REMIND_LATER

Information relevant to JAVA_HOME related problems:

  JAVA_HOME is set to: /usr/lib/jvm/java-7-openjdk-amd64/jre
  imagej.dir => /usr/share/Fiji.app

Information about the version of each plugin:

Activated update sites:
ImageJ: http://update.imagej.net/ (last check:20140701154719)
Fiji: http://fiji.sc/update/ (last check:20140702124334)

Hi Curtis,
Here is the information. You can see there is a lot of vtk stuff. This isn't in use on most systems, which also show the problem. I rarely use it as well. At the end are Postage_Action_Tool and Window_Level_Tool. I am working on them and asked Wayne for a couple of additions to make them fly. They too are not on other systems until Wayne agrees to the changes.

In short, my software is up to date. Likewise a physician in France with whom I collaborate has discovered the problem on Windows 7. He just told me this morning. He can't close Fiji, a nasty problem.

Ilan

Information about your version of Java:

  os.arch => i386
  os.name => Linux
  os.version => 3.13.0-30-generic
  java.version => 1.6.0_24
  java.vendor => Sun Microsystems Inc.
  java.runtime.name => Java(TM) SE Runtime Environment
  java.runtime.version => 1.6.0_24-b07
  java.vm.name => Java HotSpot(TM) Client VM
  java.vm.version => 19.1-b02
  java.vm.vendor => Sun Microsystems Inc.
  java.vm.info => mixed mode
  java.awt.graphicsenv => sun.awt.X11GraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.6
  sun.cpu.endian => little
  sun.desktop => gnome
  file.separator => /

The up-to-date check says: UP_TO_DATE

Information relevant to JAVA_HOME related problems:

  JAVA_HOME is set to: /home/ilan/Fiji.app/java/linux/jdk1.6.0_24//jre
  imagej.dir => /home/ilan/Fiji.app

Information about the version of each plugin:

Activated update sites:
ImageJ: http://update.imagej.net/ (last check:20140703024308)
Fiji: http://fiji.sc/update/ (last check:20140707144211)
PET-CT: http://sites.imagej.net/Ilan/ (last check:20140707092847)

Files not up-to-date:
  a46e247d (LOCAL_ONLY) 20120103101835 lib/linux32/libvtkChartsJava.so
  b3ede7e1 (LOCAL_ONLY) 20120103101835 lib/linux32/libvtkChartsJava.so.5.8
  c94d497e (LOCAL_ONLY) 20120103101835 lib/linux32/libvtkChartsJava.so.5.8.0
  02aff146 (LOCAL_ONLY) 20120103095153 lib/linux32/libvtkCommonJava.so
  b612a4cd (LOCAL_ONLY) 20120103095153 lib/linux32/libvtkCommonJava.so.5.8
  39bdf759 (LOCAL_ONLY) 20120103095153 lib/linux32/libvtkCommonJava.so.5.8.0
  40a461cc (LOCAL_ONLY) 20120103095501 lib/linux32/libvtkFilteringJava.so
  48f9018f (LOCAL_ONLY) 20120103095501 lib/linux32/libvtkFilteringJava.so.5.8
  1899375d (LOCAL_ONLY) 20120103095501 lib/linux32/libvtkFilteringJava.so.5.8.0
  712a4050 (LOCAL_ONLY) 20120103100147 lib/linux32/libvtkGenericFilteringJava.so
  72522e61 (LOCAL_ONLY) 20120103100147 lib/linux32/libvtkGenericFilteringJava.so.5.8
  f82289a5 (LOCAL_ONLY) 20120103100147 lib/linux32/libvtkGenericFilteringJava.so.5.8.0
  b01aca5c (LOCAL_ONLY) 20120103101746 lib/linux32/libvtkGeovisJava.so
  db799449 (LOCAL_ONLY) 20120103101746 lib/linux32/libvtkGeovisJava.so.5.8
  1e4de413 (LOCAL_ONLY) 20120103101746 lib/linux32/libvtkGeovisJava.so.5.8.0
  5543e3ba (LOCAL_ONLY) 20120103100130 lib/linux32/libvtkGraphicsJava.so
  55f7863f (LOCAL_ONLY) 20120103100130 lib/linux32/libvtkGraphicsJava.so.5.8
  16375cb7 (LOCAL_ONLY) 20120103100130 lib/linux32/libvtkGraphicsJava.so.5.8.0
  ee29631c (LOCAL_ONLY) 20120103101155 lib/linux32/libvtkHybridJava.so
  adbd9088 (LOCAL_ONLY) 20120103101155 lib/linux32/libvtkHybridJava.so.5.8
  1007647b (LOCAL_ONLY) 20120103101155 lib/linux32/libvtkHybridJava.so.5.8.0
  47f32ad5 (LOCAL_ONLY) 20120103100456 lib/linux32/libvtkIOJava.so
  3fd3549e (LOCAL_ONLY) 20120103100456 lib/linux32/libvtkIOJava.so.5.8
  9d3af464 (LOCAL_ONLY) 20120103100456 lib/linux32/libvtkIOJava.so.5.8.0
  04434b81 (LOCAL_ONLY) 20120103095653 lib/linux32/libvtkImagingJava.so
  dac59c32 (LOCAL_ONLY) 20120103095653 lib/linux32/libvtkImagingJava.so.5.8
  da52f13c (LOCAL_ONLY) 20120103095653 lib/linux32/libvtkImagingJava.so.5.8.0
  7e1088f5 (LOCAL_ONLY) 20120103101634 lib/linux32/libvtkInfovisJava.so
  d40ccc67 (LOCAL_ONLY) 20120103101634 lib/linux32/libvtkInfovisJava.so.5.8
  5bad1672 (LOCAL_ONLY) 20120103101634 lib/linux32/libvtkInfovisJava.so.5.8.0
  5160f481 (LOCAL_ONLY) 20120103100902 lib/linux32/libvtkRenderingJava.so
  a6c26925 (LOCAL_ONLY) 20120103100902 lib/linux32/libvtkRenderingJava.so.5.8
  bfc03e33 (LOCAL_ONLY) 20120103100902 lib/linux32/libvtkRenderingJava.so.5.8.0
  7ad40e25 (LOCAL_ONLY) 20120103101735 lib/linux32/libvtkViewsJava.so
  f897d718 (LOCAL_ONLY) 20120103101735 lib/linux32/libvtkViewsJava.so.5.8
  5731aeed (LOCAL_ONLY) 20120103101735 lib/linux32/libvtkViewsJava.so.5.8.0
  74e99696 (LOCAL_ONLY) 20120103101031 lib/linux32/libvtkVolumeRenderingJava.so
  984ee555 (LOCAL_ONLY) 20120103101031 lib/linux32/libvtkVolumeRenderingJava.so.5.8
  d95a6ae1 (LOCAL_ONLY) 20120103101031 lib/linux32/libvtkVolumeRenderingJava.so.5.8.0
  f41eeeae (LOCAL_ONLY) 20120103101434 lib/linux32/libvtkWidgetsJava.so
  a4a41242 (LOCAL_ONLY) 20120103101434 lib/linux32/libvtkWidgetsJava.so.5.8
  31e0a9a0 (LOCAL_ONLY) 20120103101434 lib/linux32/libvtkWidgetsJava.so.5.8.0
  3f8b7a08 (MODIFIED) 20140707092447 macros/AutoRun/StartupMacros.ijm
  23c5fc2d (LOCAL_ONLY) 20140625135658 macros/Macro1.ijm
  71467a9a (LOCAL_ONLY) 20140407074039 macros/Macrosalim_simpleV2.ijm
  831660de (MODIFIED) 20140701080935 macros/StartupMacros.fiji.ijm
  f7b16601 (LOCAL_ONLY) 20140703095140 macros/toolsets/Postage_Action_Tool.ijm
  6bc41fc4 (LOCAL_ONLY) 20130124080621 plugins/CT_Window_Level.jar
  aaa758e4 (MODIFIED) 20140626162109 plugins/Gastric_Emptying.jar
  e51d0400 (LOCAL_ONLY) 20100413082708 plugins/PluginsUpdater.jar
  5e0fb5fa (MODIFIED) 20140707113136 plugins/Read_CD.jar
  634d303b (LOCAL_ONLY) 20140703095140 plugins/Tools/Postage_Action_Tool.ijm
  fda14d1b (LOCAL_ONLY) 20140625083706 plugins/Tools/Window_Level_Tool.class

I can add that on our Linux box (openSuse 13.1) we often find that Fiji does
not close. It hangs, and then we close it by opening a terminal, find the process with ps -ef | grep Fiji, and then killing the process.
This occasionally happens on my OSX 10.9 system, but less often. 

We have also observed that we might close Fiji, and the windows close, but then something we thought was finished (maybe a big image file that we tried to open and thought had failed) will pop up. So it runs out that closing Fiji did not shut down all of the processes that it spawned.

For both of these events, we cannot run the bug reporter when they occur.
What is the best way to run Fiji, so that it will produce output (eg to sdterr) that might help you?

We also noticed (on the Linux box) that as we work, the response slows down, until the macro we are running fails (probably because of a timing issue, like a window that needs to open did not open in time). We ran with the monitor memory window open, to check if memory was being grabbed and not released. We did not observe this (ie, 4GB available, and < 1GB in use). Restarting Fiji will make teh macro work again.

For this last event, we should be able to use the bug reporting system to show you the state  of the program, so we will try to do that.

Hi Aryeh,
I have seen the same problem on my Ubuntu machine. To kill the process I find it easier to use System Monitor and under Processes look for either ImageJ or Fiji, usually ImageJ. The End Process button kills it.
On the Mac it is more difficult as you have to do a Force Quit.

Ilan

Hi Ilan,

On OSX I do a force quit, but I can also open a shell and use 
ps -ef | grep Fiji to find the process and kill it.

Hi,

I'm not sure if it is helpful, but I just updated Fiji, and I get the same behavior and the same error upon exiting.

Thanks,
Adam

Just a quick update: we are still actively working on the "ImageJ2 won't quit" issue, getting very close to a resolution. I believe we've finally found the root cause of the issue (actually, there were multiple "root causes") and are now refining the fix so that things still work across various scenarios.

We will get the fix uploaded ASAP and I'll follow up with a blog post explaining the nature of the difficulty, for those curious.

I uploaded a new version of the imagej-legacy library which hopefully fixes the quitting problems. Please give it a try and reopen the issue if ImageJ still does not quit. Thanks!

Hi Curtis,

I just tried it out, and it closes appropriately. However, the same error (see comment 11) is printed to the screen upon exit.

Adam

Thanks for the feedback, Adam. Glad the program closes now.

As for the warnings and exception you reported, they can be safely ignored. I do notice the same exception on Linux running OpenJDK 1.7.0_55 64-bit, which I believe happens due to a "double dispose" of the main ImageJ window. We will investigate fixing it, but in the meantime it shouldn't negatively impact your usage of ImageJ/Fiji. Please let me know otherwise.

As mentioned on the IJ mailing list, I keep on seeing this bug. Here's the requested information:

-------------- report a bug details --------------
Information about your version of Java:

  os.arch => amd64
  os.name => Linux
  os.version => 3.11.0-24-generic
  java.version => 1.6.0_24
  java.vendor => Sun Microsystems Inc.
  java.runtime.name => Java(TM) SE Runtime Environment
  java.runtime.version => 1.6.0_24-b07
  java.vm.name => Java HotSpot(TM) 64-Bit Server VM
  java.vm.version => 19.1-b02
  java.vm.vendor => Sun Microsystems Inc.
  java.vm.info => mixed mode
  java.awt.graphicsenv => sun.awt.X11GraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.6
  sun.cpu.endian => little
  sun.desktop => gnome
  file.separator => /

The up-to-date check says: REMIND_LATER

Information relevant to JAVA_HOME related problems:

  JAVA_HOME is set to: /home/noenc_ehrenfeu/usr/packages/Fiji.app.vanilla_2014-06-13/java/linux-amd64/jdk1.6.0_24//jre
  imagej.dir => /home/noenc_ehrenfeu/usr/packages/Fiji.app.vanilla_2014-06-13

Information about the version of each plugin:

Activated update sites:
ImageJ: http://update.imagej.net/ (last check:20140710195854)
Fiji: http://fiji.sc/update/ (last check:20140709223742)
IBMP-CNRS: http://www-ibmp.u-strasbg.fr/fijiupdates/ (last check:20140526164644)
IMCF Uni Basel: http://sites.imagej.net/UniBas-IMCF/ (last check:20140710225635)
-------------- report a bug details --------------

Steps to reproduce: just start Fiji with the update sites activated listed above (I did so by calling "./ImageJ-linux64"), the main ImageJ window pops up, plus the actionbar from our update site. Hitting the "X" button from the window manager decoration results in the actionbar being closed whereas the ImageJ main window stays open but doesn't accept any input anymore (mouse clicks, keyboard shortcuts). Using File > Quit is behaving the same way.

Manually closing the actionbar (again by using the "X" button) before trying to close ImageJ via the "X" button on the main window actually does work, Fiji is quitting normally then! Closing the actionbar, opening something else (e.g. "blobs", B&C, Histogram, ROIManager, ...) does not impact this, behaviour is as expected (quitting normally).

Closing *our* actionbar, then opening any other actionbar (shipped with the actionbar-plugin itself, in Plugins > ActionBar) results in the same behaviour as with ours. So it seems the actionbar plugin is pulling some trigger that makes Fiji misbehave on exit, but I guess this could also be triggered by other pieces and plugins...?

Cheers
Niko

In case this is of any interest, running Fiji with Oracle Java 1.7 (via "./ImageJ-linux64 --java-home /usr/lib/jvm/jre-7-oracle-x64") is behaving the same, except that when closing the actionbar in advance and then closing the ImageJ main window results in this error message being printed to the console:

------------------------------------------------------------------------
java.lang.reflect.InvocationTargetException
	at java.awt.EventQueue.invokeAndWait(Unknown Source)
	at java.awt.Window.doDispose(Unknown Source)
	at java.awt.Window.dispose(Unknown Source)
	at ij.ImageJ.run(ImageJ.java:767)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.IllegalArgumentException: null source
	at java.util.EventObject.<init>(Unknown Source)
	at java.awt.AWTEvent.<init>(Unknown Source)
	at java.awt.event.InvocationEvent.<init>(Unknown Source)
	at java.awt.event.InvocationEvent.<init>(Unknown Source)
	at sun.awt.X11.XBaseMenuWindow.dispose(Unknown Source)
	at java.awt.MenuComponent.removeNotify(Unknown Source)
	at java.awt.Menu.removeNotify(Unknown Source)
	at java.awt.Component.removeNotify(Unknown Source)
	at java.awt.Container.removeNotify(Unknown Source)
	at java.awt.Window.removeNotify(Unknown Source)
	at java.awt.Frame.removeNotify(Unknown Source)
	at java.awt.Window$1DisposeAction.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$200(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue$4.run(Unknown Source)
	at java.awt.EventQueue$4.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)
------------------------------------------------------------------------

Hi Niko,
I just tried it this morning and it seems to work for me.
Since the update is so new, the "Remind Later" probably means you are still running the old version. Try Help -> Update Fiji, and get the latest software and give it another try.

Ilan

Hi Ilan,

the "Remind Later" only means that I clicked away the update dialog after the startup of Fiji. Still, I did run it manually later on.

~Niko

Just tested on Win7x64, behaviour is very similar except for that the ImageJ main window is still accepting clicks on the menus (including sub-menus) /after/ hitting the "X" button. Buttons on the toolbar don't respond to clicks any more neither do keyboard shortcuts work (like Ctrl-L).

Hi Niko,
Your freeze of the keyboard etc is exactly what I would see before the fix. After this morning's fix that has all gone away. Just for kicks, maybe try to update it again?
I am on Linux-32 and you are on Windows-64 so there could be a difference.

Ilan

Hi Ilan,

believe me, I *really* made sure to have everything updated - more than just once, and on all platforms investigated ;-)

I am usually /not/ on Win-64 but on Linux-64, the last comment was just additional information as I could also reproduce it on the Windows platform.

My blind guess is that you don't have any ActionBars open, which I identified as causing this problem on my side (see comment #30 above), right?

Cheers
Niko

Hi Niko,
I'll admit that I didn't notice your action bar statement. In my case I have my Pet-Ct viewer running, as well as B&C and my Read from CD. If these qualify as action bars, then I do have some running. Obviously I don't have your action bar as I don't know what it does.

I have something strange which you might just know the answer to. With my Pet-Ct viewer and Read from CD, there is a title clearly appearing on each bar, but when I hit Window on the Fiji menu, I see B&C listed but I don't see my stuff listed. For my stuff I see only a box, like next to B&C, but no text for the Window. I can't figure out what I am missing.

Thanks,
Ilan

Hi Niko,
Way back when Curtis told me I had to add

	private void init() {
		WindowManager.addWindow(this);

the WindowManager.addWindow for Fiji to close my program. I did it inside my init routine. Do you have such a call?

Ilan

Hi Ilan,

ActionBar is a plugin for ImageJ, and it also has a Fiji update site (you can see it in the list of activated sites in my "bug report details" section from above). It is described on the ImageJ wiki on http://imagejdocu.tudor.lu/doku.php?id=plugin:utilities:action_bar:start 

So if you don't know what ActionBars are, you probably don't have them, and this would also be the reason why you're unaffected by the behaviour I'm describing ;-)

For your second comment, that one I really don't get. To me this looks as if something ate away half of your comment (at least one missing "}", but even with that I have no clue what it is supposed to do, or where).

Cheers
Niko

Niko,

Ilan's comments were in reference to these methods of WindowManager: https://github.com/imagej/ImageJA/blob/master/src/main/java/ij/WindowManager.java#L239-264

Essentially, best practice is that when software creates a Frame, Window or ImageWindow the created object should register itself in the WindowManager on instantiation.

This exposes the object so that, for example, the shutdown routine in ImageJ2 can attempt to use the WindowManager to close all active Windows explicitly (to avoid the necessity of a System.exit(0) call, which was always being called in ImageJ 1.x, for example).

However, this is clearly fragile as it means that anyone can create a plugin that accidentally or intentionally creates windows without registering them, which will lead to ImageJ not shutting down properly.

I was under the impression that manual window registration isn't explicitly necessary right now and we're still falling back to IJ 1.x's System.exit calls... but I'm not 100% sure based on Curtis's latest fixes for this closing issue.

Also I confirm that trying to close Fiji with an ActionBar open causes the ActionBar to close (or at least go invisible.. which could be an important distinction) but Fiji to remain open and unresponsive.

Closing the ActionBar first allows Fiji to close as usual.

Thanks Mark for the clarification (and of course thanks Ilan for your suggestions!).

I'm pretty sure we can ask Jérôme (the author of the ActionBar plugin) to fix this in the source code in case this is really the reason of this issue. Maybe we can even mavenize the ActionBar plugin... I'd love to do that as an exercise, but currently my schedule is so packed, I'm afraid I won't find the time for it :-(

I do not think failure to register your windows is the issue.. it looks like the IJ2 code that closes the windows (https://github.com/imagej/imagej-legacy/blob/master/src/main/java/net/imagej/legacy/IJ1Helper.java#L205-219) is not even being called when attempting to shut down with an ActionBar open.

investigating further...

Confirmed:

The problem is with attempting to dispose windows after dispatching a WINDOW_CLOSING event: https://github.com/imagej/imagej-legacy/blob/master/src/main/java/net/imagej/legacy/DefaultLegacyHooks.java#L536

WINDOW_CLOSING events for the ActionBar trigger a WindowManager.removeWindow call. This method is synchronized, as is the intercepted WindowManager.closeAllWindows method.

This causes removeWindow to block the EDT until closeAllWindows complets. So when Window.dispose() is called from closeallWindows, a dispose action is attempted to be invoked the EDT, which leads to a deadlock.

Niko Ehrenfeuchter wrote:
> Caused by: java.lang.IllegalArgumentException: null source

The "null source" bug is a separate problem, documented at:

   https://github.com/fiji/fiji/issues/94

Note that our current belief is that this exception is _not_ actually a crash, meaning it does not block shutdown. Also, this "null source" bug is limited to recent versions of OpenJDK 7 on Linux.

As for the actual quitting problem with ActionBar: it is a deadlock between the Quit and EDT threads due to WindowManager having synchronized methods. We have a fix in the works right now, which we will upload later today.

Generally speaking, the fix will also make quitting less deadlock prone, and less likely to block shutdown altogether due to misbehaving windows (i.e., windows with WindowListeners that do evil things with windowClosing).

OK, we have uploaded another slew of fixes, and dubbed it ImageJ 2.0.0-rc-9. Once again, we believe the quitting problems to be fixed. Please test again and let us know how it goes.

Seems to be solved for me now! Thanks A LOT to all of you guys, amazing work!

*** Bug 847 has been marked as a duplicate of this bug. ***