NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 874 - Headless ImageJ2 takes about a minute extra to exit after finishing script or macro
Headless ImageJ2 takes about a minute extra to exit after finishing script or...
Product: ImageJ
Classification: Unclassified
Component: Legacy
PC Linux
: P5 normal
Assigned To: Curtis Rueden
Depends on:
Reported: 2014-07-31 09:13 CDT by Paul van Schayck
Modified: 2016-02-26 14:35 CST
3 users (show)

See Also:

ImageJ2 properties (5.47 KB, text/plain)
2014-07-31 09:13 CDT, Paul van Schayck
Java heap dump (5.34 KB, text/plain)
2014-07-31 09:14 CDT, Paul van Schayck

Description Paul van Schayck 2014-07-31 09:13:03 CDT
Created attachment 188
ImageJ2 properties

In the daily version of ImageJ2, when running a script like this:

./ImageJ-linux64 --headless -macro scripts/short.js

Takes about a minute after completion of the script to return to command line. The script contains "print('foo')". It also happens with macros (.ijm). 

I can reproduce this on a wide variety of linux installs and JRE's. But it only happens in pure ImageJ2, when installing the daily version of Fiji it does not happen. 

When adding eval("script", "System.exit(0);"); it is fixed. Using run('Quit'); has no effect.

I'll attach the Java heap dump while waiting for ImageJ to exit. The ImageJ properties output has been attached already.
Comment 1 Paul van Schayck 2014-07-31 09:14:06 CDT
Created attachment 189
Java heap dump

Java heap dump while waiting for ImageJ2 to finish
Comment 2 phsiao 2015-03-24 15:05:45 CDT
I use 'eval("script", "System.exit(0);");' at the end of the macro to get around this issue.
Comment 3 Curtis Rueden 2015-03-24 15:26:38 CDT
Sorry this issue slipped through the cracks till now, Paul.

Unfortunately, looking at the thread dump, I have no clue why there is such a delay in shutdown. None of the threads are doing anything -- all is idle.
Comment 4 Paul van Schayck 2015-03-24 16:16:06 CDT
Hi Curtis,

No worries. Using System.exit(0); is an acceptable work arround for us.

However, fixing it could be nice. I can still reproduce the bug, right now on a completely different Linux system as above.

Is there anything I could to do to help you debug it? I've been looking for example through a `strace` output. What I can see is that that several calls are made to the ~/.java/.userPrefs/ directory during the wait. I'm not sure it is related at all, but as I guess you can't reproduce this on MacOSx, it be must be something linux specific.


Comment 5 Curtis Rueden 2015-03-24 16:50:31 CDT
> I guess you can't reproduce this on MacOSx

Actually, I cannot reproduce on OS X, nor on an Ubuntu Linux 12.04 system with a Fiji updated just now.

Furthermore, I do not have the first clue how to debug an issue like this, when there is an unhelpful stack trace. If my job depended on debugging it, I would do a slew of web searches, and send some mails to relevant Java mailing list(s).

Sorry I can't be more helpful. :-(
Comment 6 Paul van Schayck 2015-03-25 04:14:44 CDT
Ah! But that's a crucial bit. A few months a go this did not happen using Fiji, but only when using pure ImageJ2. 

However trying today this also happens with Fiji. Something changed in that aspect in the last few months.

Do you see in pure ImageJ2? I'll try download some of the older versions of Fiji.
Comment 7 Mark Hiner 2016-02-22 13:41:58 CST
Typically when there is a "ImageJ won't quit" issue it is due to a Context not being disposed.

There was also a bug due to the single-instance listener for ImageJ not being disconnected on shutdown.

I can reproduce this behavior on linux; both of these issues will be fixed in the next IJ2 release, resolving the problem with headless shutdown locally.



for the fixes to these issues.
Comment 8 Mark Hiner 2016-02-26 14:35:34 CST
This should now be fixed (requires the Java 8 update site).

Please re-open if you are still getting "won't quit/slow to quit" problems.