out of memory error on loadImage()?

edited January 2018 in Questions about Code

Never have got this before. Sketch stops after 1000's of iterations in draw loop at a img=loadImage("c:/avssmth/smthimg.png"); statement. This loadImage is in a If statement , the condition only happens 4-5 times each draw loop so that should not be the problem. Are there requirements to unload to free memory back up for subsequent statements that use memory?

Answers

  • edited January 2018

    In general, if at all possible, don't use loadImage() in draw. Use it in setup().

    1. In setup(), load your images once into img / img2 / img3 or into PImage[] images.
    2. in draw() reference them as many times as you like in your draw loop -- referencing them will not allocate new memory, because you aren't uselessly creating and destroying objects for the same smthimg.png many times per second.
  • Not possible for my application. I create PImage img in setup. But my draw loop calls a outside utility to grab new image to a .png file. Then I load the img with loadImage() in draw loop and display. Is there something I can do to insure loadImage does not leave memory behind when called multiple times ?

  • I good way to start is providing a minimum example reproducing the problem. If people can reproduce it, they will toss ideas around...

    Kf

  • Hmm. I'm not sure. Here is how loadImage works:

    https://github.com/processing/processing/blob/e83ae2054a3d3c52b1663385673fdfb26abcc96b/core/src/processing/core/PApplet.java#L5360

    ...and it uses ImageIO:

    • import javax.imageio.ImageIO;

    I wonder if using an array of five image objects in your draw loop would help the garbage collector keep up with all the orphans.

  • the problem doesn't happen until 100's of loops of draw successfully working. So its hard to code a minimum example that actually exhibits the problem. I have found numerous occasions where a small test program i use to learn how things work in Processing often has problems when incorporated into a larger Processing application. Particularly when it has to do with loading files or images. I have a sketch now that runs over 22000 times in the same draw loop and then generates a file missing or inaccessible error! After numerous attempts to solve it seems it is a timing issue as to when the files is completely written and when loadImage "sees" it. Adding a delay worked at first , but when run over and over occassionally after 1000's of loops it generates a file missing error! If i increase the delay time it takes longer to happen, but a delay of 1000, a second is unacceptable. And the check for the file exists is not enough. So i continue to find a workaround. Possibly catching the error and retrying the loadImage till it works? But can't find what exception class to use!

    A simple change to a string to add dots to show progress inside the loop is the only change and when run now generates out of memory error after 3500 iterations in draw. Perplexing and I feel like there are a lot of "conditions" i am discovering that need work arounds of some kind to make Processing work. I have programmed in C for over 20 years and never had problems like this. Once something works, adding another function or minor changes in code didn't cause programs not to run unless somthing was wrong with the added code which once debugged solved the problem. But loadImage can work and then after 3000 calls cause an error!

  • A simple change to a string to add dots to show progress inside the loop is the only change and when run now generates out of memory error after 3500 iterations in draw.

    It sounds like print / println might be the culprit here:

    Note that the console is relatively slow. It works well for occasional messages, but does not support high-speed, real-time output (such as at 60 frames per second). It should also be noted, that a println() within a for loop can sometimes lock up the program, and cause the sketch to freeze.

  • edited January 2018

    the long-standing println bug was apparently fixed in 3.3.4

    0261 (3.3.4)
    X redo console handling to not use Timer, fixing freeze-up problems
    o  github.com/processing/processing/pull/4935
    X github.com/processing/processing/issues/4825
    
  • no using any println, progress is shown by text to screen of string as dots added to string. string is reset to "." at start of each loop.

  • Is there a way for me to chk how much memory the sketch is using and put up a CLOSE AND REOPEN message to the user periodically before the OOM erro ocurrs as a patch for the problem?

  • ok so I chk memory at start of sketch with

         int maxMemory, totalMemory, freeMemory, percentage;
    
          maxMemory = int(Runtime.getRuntime().maxMemory()/1000000);
          totalMemory = int(Runtime.getRuntime().totalMemory()/1000000);
          freeMemory = int(Runtime.getRuntime().freeMemory()/1000000);
          percentage = int((float)totalMemory/maxMemory*100);
          println(" | max: " + maxMemory + " | total: " + totalMemory + " (" +    percentage + "%)" + " | free: " + freeMemory);
    

    then i write this info to a .txt file at end of every loop and see what it is when the sketch gives out of memory

    At start I get : max=915 free=61 %=42 when it stops the last numbers written to the file are: max=849 free=65 %=35

    Shouldn't these indicate a out of memory approaching?

    What number would be the one to signal running out of memory?

  • So the Java garbage collection and memory management works in the background . In post from 2016 from Henri , "PImage won't release memopry" KevinWorkman says the Java garbage collection and memory management works in the background so "Out of Memory" error should never happen. Wonder if it is fixed in later versions or what cause I get it in the following scenerio.

This discussion has been closed.