Login  Register

Re: Out of Memory Problems

Posted by Michael Schmid on Jul 25, 2013; 3:23pm
URL: http://imagej.273.s1.nabble.com/Out-of-Memory-Problems-tp5004033p5004143.html

Hi Hans & everyone,

It is the same memory leak with (Sun/Oracle/Apple) Java 1.6 on Mac OS X 10.6.8, so it is not a problem of the Java virtual machine.

Strange enough, "Close All" seems to nicely clean the list of BatchMode images: print(nImages) gives the full number before, but 0 thereafter.

Nevertheless, these images seem to be not garbage-collectable.

It's the same problem if:
- I open a .jpg instead of creating a new 8-bit image in the separate thread, so 'newImage' does not cause the problem.
- I replace doCommand by run("open image in new thread");

I have looked into the sources but found nothing where a reference to these images would remain.  The only remote possibility is that java keeps references to the old threads somewhere, and the thread keeps a reference to the Interpreter, where the ImagePlus is referred to as batchMacroImage.

In any case, maybe ImagePlus.close() should call flush() if there is no image window, to make sure everything is cleaned up?
(For images that have an associated ImageWindow, closing the ImageWindow calls flush of the ImagePlus.)
I don't understand why it should be a problem in the present case, but there might be cases with ROIs associate to an ImagePlus, there the roi holds a reference to the ImagePlus and vice versa, and it won't be garbage collectable in BatchMode.


Michael
________________________________________________________________
On Jul 25, 2013, at 15:14, Hans Wurscht wrote:

> Dear List,
>
> I experience the same problem when using the doCommand in a macro:
>
> openImage();
>
> macro "open image in new thread"{
> newImage("Untitled", "8-bit white", 400, 400, 1);
>
> }
>
> function openImage(){
> setBatchMode(true);
> for(i=0;i<1000;i++){
> doCommand("open image in new thread");
> wait(100);
> }
> wait(3000);
> run("Close All");
> setBatchMode(false);
>
> }
>
> Once finished, you can see that the threads are terminated, but the
> memory is not freed up.
>
> Running the garbage collector from the menu does not help. I use the
> doComand option to run some live analyis during timelapse recordings,
> and this bug leads to an out of memory error and failue of the
> analysis.
>
> I tried IJ 1.47u, 1.48a with openJDK 6 / 7 on Ubuntu 12.04 32bit
> without success.
>
> Do you have any suggestions for me?
>
> Thanks a lot,
>
> Gabriel
>
>
> On Jul 23, 2013, at 1:34 PM, Johannes Schindelin wrote:
>
>> Hi Olivier,
>>
>> On Tue, 23 Jul 2013, Burri Olivier wrote:
>>
>>> I've tried loading a large dataset over and over through a macro (Load,
>>> close loop) after updating Fiji And I still get the out of memory error.
>>
>> Well, this is my fault. For some reason, I failed to upload a new version
>> of ij-legacy.jar when I said that I had. But now it worked, and this
>> beautiful macro demonstrates that my fix works at least with the Clown
>> sample (I was unable to run Plugins>Utilities>Monitor Memory... from the
>> macro without blocking the rest of the commands, so please call that by
>> hand before running it):
>
> A macro can run Plugins>Utilities>Monitor Memory without blocking by
> using the doCommand() macro function, which runs a menu command in a
> separate thread. For example, this macro starts the Memory Monitor and
> then opens and closes 5000 1MB images.
>
>  setBatchMode(true);
>  doCommand("Monitor Memory...");
>  n = 5000;
>  for (i = 0; i < n; i++) {
>     showStatus((i+1)+"/"+n);
>     newImage("Untitled", "8-bit ramp", 1024, 1024, 1);
>     close();
>  }
>
> -wayne
>
>> path = getDirectory("imagej") + "samples/clown.jpg";
>> useBF = true;
>> setBatchMode(true);
>> for (i = 0; i < 100; i++) {
>> if (useBF) {
>> run("Bio-Formats", "open=[" + path + "] "
>> + "autoscale color_mode=Default "
>> + "view=Hyperstack stack_order=XYCZT");
>> } else {
>> open(path);
>> }
>> close();
>> }
>>
>> For easy debugging and extensive testing, I also tried with "!true" for
>> both useBF and setBatchMode(), and the issues that I could indeed
>> reproduce with the Fiji version as of half an hour ago are now gone.
>>
>> Ciao,
>> Dscho
>>
>> P.S.: The macro assumes that you have unpacked Fiji into your home
>> directory and that you ran File>Open Samples>Cache Sample Images. This is
>> so far a Fiji-only function (Wayne, if you read this and re-implement it
>> for ImageJ 1.x, please let me know so that I can prevent breakages in
>> Fiji).
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> Top of Message<https://list.nih.gov/cgi-bin/wa.exe?A2=ind1307&L=IMAGEJ&P=R56424&1=IMAGEJ&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4#TOP>|
> Previous
> Page<https://list.nih.gov/cgi-bin/wa.exe?A1=ind1307&L=IMAGEJ&D=0&1=IMAGEJ&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4>|
> Permalink <https://list.nih.gov/cgi-bin/wa.exe?A2=IMAGEJ;b6ecca0f.1307>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html