Repeatable crashes

Hello. I hope I’m at the right place. I’m having problems running a very simple macro in Fiji, which I’ve only just found out about. I’m trying to assemble huge 10 x 10 image tiles into a single file using the stacks and montage. This works just fine when I do it once (no virtual stack, scale at 1.00, all other options set to default). Twice works as well. On the third time the app invariably crashes. It doesn’t matter if I’m using my macro or manipulating the GUI manually, I always get a crash at the third batch. I am stretching the RAM limits of my machine (this is how I found that 10 x 10 montages are the maximum I can do), but the process should be repeatable. It looks like there’s a memory leak somewhere. I’ve attached a crash log in case anyone has the time to look.

Thank you very much.

Config: macOS 10.14.5 on iMac 27 Late 2015, 24gb RAM. Java 8 Update 221 build 11.

hs_err_pid2748.log.zip (13.4 KB)

Hey @Cirrocumulus,

would you mind sharing the macro you are using? And maybe some example data? We could then try to reproduce the bug on our machines…

Thanks!
Robert

1 Like

Thank you for replying! Like I wrote, I believe the actual macro is irrelevant because the crash happens even if I do the actions manually, but I don’t mind sharing it here. It’s just a very basic little loop that goes over a sequence of folders with specific known names, each of them containing 100 images, and making a montage of each. The example below would create four of those out of a total of 400 images (or it would, if it didn’t crash on the third one…) You can safely ignore all the string formatting before the File.exists check, the sequence of actions that causes the problem is the one following that. Please forgive the crude style, this was done very quickly!

for (y = 0; y < 20; y+=10) {
	for (x = 0; x < 20; x+=10) {
        
        // Format the subdir name and filename
        yStart = IJ.pad(y, 3);
        yEnd   = IJ.pad(y + 9, 3);
        xStart = IJ.pad(x, 3);
        xEnd   = IJ.pad(x + 9, 3);
        subgrid = yStart + '-' + xStart + '-' + yEnd + '-' + xEnd;
        filename = "/Volumes/Disk/MontageFolder/" + subgrid + ".tif";

        // Skip existing files
        if (!File.exists(filename)) {
        	print('Processing ' + subgrid);
	        run("Image Sequence...", "open=[/Volumes/Disk/SourceFolder/" + subgrid + "] sort");
		run("Make Montage...", "columns=10 rows=10 scale=1");
		print('Saving ' + subgrid);
		saveAs("Tiff", filename);
		print('Saved ' + subgrid);
		close();
		selectWindow(subgrid);
		close();
		print('Done');	
        }
}
}

I can’t share the files I’m using but it’s very easy to simulate. These are 8-bit-per-channel RGB png files, 3840x2160 px and 10-15 mb each. If you want to test this you could download an image like this one, resize it (original aspect ratio is different but you can crop or distort it to 3840x2160, it doesn’t matter), save it as PNG (I used “largest file size” in Photoshop), duplicate it 99 times in the same folder and rename them as a sequence (e.g. file000 to file099). You would get essentially the same thing I have here. Then duplicate your entire folder a few times.

Thank you very much for your help.

What is the RAM of your machine and the memory settings in Fiji?
You can look the memory settings in Fiji up under:
Edit > Options > Memory&Threads…

You should not use more than 70-80% of your available RAM otherwise Fiji can become unstable. You could throw in a Garbage Collection after you closed the files. Usually Fiji should do that automatically but it does not hurt:

run("Collect Garbage");

You can also monitor memory usage of Fiji via:
Plugins > Utilities > Monitor Memory…

2 Likes

Thank you. I’ve added the Garbage Collection command to the end of the inner loop. In the next run the macro ran 3 times before crashing on the 4th (instead of 2 and crashing on the 3rd), but it might be related to something else (I had closed all running apps before the last test).

My machine has 24 gb of RAM and the memory setting in Fiji is the default one, which is 17778 mb.

During the last test I seem to have confirmed a problem with the cycle (again, not the macro, same thing happens when doing the montages sequentially by hand), by using the Monitor Memory window. At each iteration, I see memory usage climbing in a sawtooth pattern from <%1 to a higher value, before going back to <%1 at the start of the next cycle. However, the maximum value reached at each cycle is significantly higher than the previous one (although still far from maximum), which shouldn’t be the case since the files are basically identical:

  1. 7 gb — 39%
  2. 7.8 gb — 44%
  3. 9.1 gb — 51%
  4. 39% seen just before crash

I should add that the crashes invariably happen while saving the file, although when doing this manually they occur a few seconds after the montage is displayed (which probably amounts to the same thing).

A workable solution : in case it helps someone in the future, I’ve managed to circumvent the issue by running the macro headless from the command line. On macOS, the easiest way is to dig into the Fiji.app package using “View Package Contents”, all the way into “/Contents/MacOS”. Open this folder in Terminal and enter:

./ImageJ-macosx --headless -macro /Path/to/macro/Macro-Name.ijm 

I’m using the exact same setup described in my posts above and the macro has gone through dozens of iterations with no issues. There was a significant increase in swap file usage on my Mac but the process didn’t crash and was concluded successfully (although I couldn’t find a way to make it use more than one CPU core).

1 Like

Thanks for posting a solution.

Hm maybe using the batchmode setBatchMode(true); in the script then is another way to circumvent this problem. Does not really smell like a memory issue though…

How many threads it can use depends on the plugin itself the headless mode will not help there. You could parallelize by calling multiple instances of Fiji maybe…if the OS does it that way, I never tried. Simply chunking your data with a bash script and then passing which chunk each Fiji instance should process via headless could do the trick…

Thanks. I think I’ll just leave it to calculate for as long as it takes, one core or not. I’m already happy it crunches everything without crashing. :slight_smile:

@Cirrocumulus Thanks for the crash log. These sorts of crashes are usually bugs in Java, as opposed to bugs in ImageJ or its plugins.

Firstly: there is an “If ImageJ crashes” section of the Troubleshooting page:

The advice there is brief—mostly just to launch ImageJ from the command line to see if there are any messages on the console. But I still encourage everyone who answers ImageJ questions to link to the relevant ImageJ wiki content, since it expands the utility of your answer. And if your answer is general-purpose and wiki content does not yet exist, then create it.

In this case, the crash report shows the crash happening here:

# C  [libawt.dylib+0x314ec]  IntRgbBilinearTransformHelper+0x9d

I found one post on StackOverflow with the same/similar issue:

No definitive answer, but there is a suggestion that it could be a threading issue, with AWT calls being erroneously made from a non-EDT thread. So this could be a bug on the Java side after all.

Have you tried running ImageJ with a different version of Java? The latest version of Java 8 is 1.8.0_222 (you are running 1.8.0_202). You could also try with the latest Java 11 and/or Java 12 to see if it makes a difference.

Java can be downloaded here:

1 Like