Created attachment 201
full text of exception

Created attachment 202
macro which I was running

Additional note: every time I run the script, a new set of such directories is created. Each appears to contain a plugin which I am using in the script.
Each time I run the script, three such directories are created.

We just noticed also the when this script starts, we get the following exception:

(Fiji Is Just) ImageJ 2.0.0-rc-13/1.49f7; Java 1.6.0_24 [64-bit]; Linux 3.11.10-11-desktop; 119MB of 4625MB (2%)
 
java.lang.StackOverflowError
	at net.imagej.legacy.LegacyOutputTracker.getTracker(LegacyOutputTracker.java:166)
	at net.imagej.legacy.LegacyOutputTracker.removeOutput(LegacyOutputTracker.java:99)
	at net.imagej.legacy.DefaultLegacyHooks.unregisterImage(DefaultLegacyHooks.java:187)
	at ij.gui.ImageWindow.close(ImageWindow.java)
	at ij.gui.StackWindow.close(StackWindow.java:182)
	at ...

I attached the full exception text and the macro. I note that after receiving the exception, the macro appears to function correctly.

More information:

This error occurs when I do:

run("Close All");

this also happen when I run it from the menu.

Something else (sorry , I did not expect it).

When I try to manually close the images, most of them close , but two of them 
fail, and generate the exception:

(Fiji Is Just) ImageJ 2.0.0-rc-13/1.49f7; Java 1.6.0_24 [64-bit]; Linux 3.11.10-11-desktop; 89MB of 4625MB (1%)
 
java.lang.StackOverflowError
	at net.imagej.legacy.Utils.findLegacyThreadGroup(Utils.java:56)
	at net.imagej.legacy.LegacyOutputTracker.getTracker(LegacyOutputTracker.java:166)
	at net.imagej.legacy.LegacyOutputTracker.removeOutput(LegacyOutputTracker.java:99)
	at net.imagej.legacy.DefaultLegacyHooks.unregisterImage(DefaultLegacyHooks.java:187)
	at ij.gui.ImageWindow.close(ImageWindow.java)
	at ij.gui.StackWindow.close(StackWindow.java:182)

etc.

The StackOverflowError messages are a symptom of a different bug, which I fixed yesterday:
https://github.com/imagej/imagej-legacy/commit/2729b90ed8b1e0ab349172f6b0d641c8d3572a9e

That fix is being released and uploaded as I write this. But I will leave this issue open since it is primarily about the proliferation of temporary directories.

Thank you. 
Why did it only fail for some images, and not for most of them?

I did not duplicate the exact circumstance you had with the StackOverflowError (I saw the error in a slightly different situation, after some code changes locally). So I cannot be certain why it only happens for some images. But if I had to speculate, I'd say maybe a race condition (multiple threads modifying data structures at the same time).

In any case, please let me know if you still see StackOverflowErrors after updating, while the "Enable ImageJ2 data structures" option is OFF (which it is by default now).

I fear that this code is not called: https://github.com/scijava/scripting-java/blob/1c965a106eed858523d0e8c0ec663fab4caaa628/src/main/java/org/scijava/plugins/scripting/java/JavaEngine.java#L329-L342 (it is supposed to clean up the temporary directory after use)

I did not see that stack overflow error following the most recent update.
I cannot be sure that this problem is solved, because in the past it only occurred with some images. However, I tried to reproduce the previous workflow, and did not reproduce the error. So it looks like this part is solved.

Hi everyone,

I encounter the exact same problem as Aryeh.

I just got the latest stable release of Fiji 2 days ago, and also updated again when the problem started.

I am running Fiji on a Windows 7 64-bit system. 
SCIFIO is by default turned off (I checked).

My macro is extremely simple, I just use the Color Deconvolution Plugin repeatedly for some 600 microscopy images (quite large, about 3000x4000).

// some directories are retrieved before
for(i = 0; i < list.length; i++) 
{
	input = dir1+list[i];
	print(input);

	run("Open [Image IO]", "image=["+input+"]");
	run("Colour Deconvolution", "vectors=[Embryo Anatomie II] hide");
		
	if(isOpen(4))
	{
		selectImage(4);
		run("RGB Color");
		saveAs("Tiff", dir2 + list[i]);
	}
			
	run("Close All");
}

What happens is the following:
for every image a directory named java########## (##### being some large number, as it was with Aryeh) is created in my temp directory, contents are further directories src, target, and a file (the culprit) pom.xml.
pom.xml starts with about 66kB, but DOUBLES for each image, reaching about 68 MB after 12 images. The execution time increases significantly, so that I have to process the images in chunks of about 10 images.
So apparently pom.xml is somehow internally reset after the macro finished (that's how I imagine it).

So it seems to me the problem was not yet solved. Or do you have any ideas? Thanks in advance.

mone7979 - I was unable to reproduce this on my windows machine with the latest Fiji.

I tried running macros and the individual commands, with and without SCIFIO, and the only temporary file I saw pop up was a mapdb file (which SCIFIO does use) that was deleted appropriately when Fiji quit.

>I just got the latest stable release

Can you clarify which download you used? Was it the "Fiji continuous release"? If not I would recommend trying that, or running Help > Update Fiji.

If you're still seeing this problem with the latest Fiji, would you mind creating a minimal script (i.e. one that can be run anywhere without requiring modification - by using the sample images, for example) that causes this problem on your system?

Thank you!
- Mark

P.S. In addition to an up-to-date Fiji, let us know if you have any extra update sites or plugins installed. This info is reported in the Help > Report a Bug dialog from Fiji.

Created attachment 229
Minimal example for error reproduction. Contains deconv.ijm macro and an image directory.

Hi,

I forgot to mention that I used the .java/.class versions downloaded from the project website, as I had to add my own color vectors to the menu. Maybe that's the crucial part?

Anyhow, I again downloaded the Fiji Win32 continuous release version today, and put the .java/.class files from the colour deconvolution project website to the plugin directory.

For reproducing the error it is sufficient to just use the deconvolution with any of the color vectors, the test case is attatched. It contains the deconv.ijm macro, and a directory with 15 images. 

When running the macro, processing time starts to noticeably increase after about 10 images. Again, for every image a directory called javaXXXXXXX is created in my Temp directory, with increasing file size of pom.xml.

Hope you can reproduce the error now.

Thanks and have a nice day,
Simone

Thanks mone7979. Unfortunately, it looks like the attachment you uploaded is somehow only a text file containing the description, rather than the ZIP file as intended.

However, I had an idea for a possible fix, which I would like you to test.

Please download this file:
  http://curtis.imagej.net/fiji-bug-906/scripting-java-0.2.6-SNAPSHOT.jar

Place it in your Fiji.app/jars directory, and delete the old scripting-java-0.2.5.jar.

Then start Fiji, try to reproduce the problem again using your workflow, and let us know how it goes.

If this change fixes the problem for you, we will release it to the ImageJ update site.

P.S. In case you're curious, the relevant code change (as pointed out by Johannes a while ago in this thread) is:

  https://github.com/scijava/scripting-java/compare/fix-tmp-proliferation

Created attachment 234
Minimal example for error reproduction. Contains deconv.ijm macro and an image directory.

@mone7979 Does the problem still occur with my updated scripting-java snapshot JAR?

Hi,

sorry for the late answer, and thanks for you taking care of my problem. I followed your instructions, but unfortunately it still shows the same behavior.

I attatched the .zip file containing the minimal example, this time apparently correctly...

Hopefully you can reproduce the error. Otherwise I have no clue what to do. 

Regarding my task, I just applied the script like 60 times in chunks of about 10 images to do the color deconvolution of the whole data set. Probably I will not need this functionality any more. But still, apparently this error happens also for other people, so maybe my example can help to find the problem?

Another idea, did you try to reproduce the error with the colour-deconvolution .jar that comes when fiji is downloaded? Maybe it's something that only happens with the download-version of the project webpage, which I had to use since I had to adapt something in the source code.

Bye,
Simone

Thanks for the quick follow-up.

> did you try to reproduce the error with the colour-deconvolution .jar
> that comes when fiji is downloaded? Maybe it's something that only
> happens with the download-version of the project webpage, which I had
> to use since I had to adapt something in the source code.

That theory makes sense. I did not test with the downloaded version. And I could not reproduce the issue with your example macro + files on my OS X system.

It would be very helpful if you could verify whether the problem still occurs on your system with the stock Colour Deconvolution JAR, rather than the modified version.

Alternately, you can use the File > Make Fiji Package command to zip up your installation, and then upload that somewhere (e.g., Dropbox), which will increase our chances of being able to reproduce.

So, my theory was correct, the error does not appear when I use the included version, only with the .class/.java version. 

I can for sure say that the problem was not caused by the modifications I made, since I just added an additional staining in the code, just another set of vectors. 

Probably fixing the error is then more a task for the original developers of the project?

Anyhow, thank you very much for your help. If you think some more input from me is necessary, I am happy to provide it.

Simone