From f...@processing.org on October 29, 2012 12:18:50
Hm, shouldn't be happening since the cache objects are connected by weak references. But maybe something isn't wired correctly there.

What happens if you set frameRate(10) or 20 inside setup()? I wonder if the (heavyweight) createGraphics() and image() calls aren't allowing any sleep time between draw() calls and therefore starving the GC.

From fjen...@gmail.com on October 29, 2012 13:36:57
No, neither frameRate(1) or calling System.gc() every nth frame helps. ... The choking would happen too when the image() call is removed but that cures the problem. So it needs to be somewhere in there ..

From f...@processing.org on October 29, 2012 13:40:31
k thanks; sounds like there's just a bug in how the weak references are implemented since they're not getting collected.

From nonsequi...@gmail.com on November 18, 2012 02:17:03
I think the same bug is causing big problems for me, but I thought loadImage was the culprit. Here's a simple sketch that causes memory use to climb rapidly. Lowering framerate or sleeping doesn't help. Same problem on Mac 64 and Win 64 if that helps.

String[] img_filenames;

void setup()
{
// filenames for two small images
// (mine are about 128 x 128)
img_filenames = new String[2];
img_filenames[0] = "/Users/dan/Documents/Owens Archive Crops/thumb/1857.1.jpg";
img_filenames[1] = "/Users/dan/Documents/Owens Archive Crops/thumb/1949.27.jpg";
frameRate(10); // tried different rates to give GC time, doesn't help
}

int i = 0; // image filename index

void draw()
{
PImage img = loadImage(img_filenames[i]); // load image
image(img, 0, 0); // display image
i = (i + 1) % img_filenames.length; // index of next image
}

From f...@processing.org on November 18, 2012 03:08:29
No, comment #5 is a programming error. You should never use loadImage() inside draw(), otherwise you're re-loading the image files (not a small amount of memory) 60 times every second. That's a bad idea.

From nonsequi...@gmail.com on November 18, 2012 13:25:51
My code example in comment #5 is artificial to illustrate a memory leak with loadImage() or PImage. Sure this toy example is poor programming style, but re-loading an image should not consume more memory, just more CPU -- whether in draw() or other places.

I have an app that runs all day in a gallery and essentially displays random images loaded from disk. There are thousands of possible images, so I have to load them on demand. I have to use loadImage() constantly and it's causing a memory leak.

From igno...@gmail.com on November 29, 2012 23:27:58
This seems to be the same issue I have encountered in assigning a supposedly temporary PImage variable in a method, see https://forum.processing.org/topic/pimage-memory-leak-example#25080000001807951.

PhiLho offered a more compact example than mine, with a workaround:

void draw()
{
  PImage img = createImage(width, height, RGB);   // leak
  image(img, 0, 0);
  g.removeCache(img);                             // workaround
  println(frameCount + " " + g.getCache(img));
}

The same problem occurs outside a tight loop, in my example. I've tracked it with JConsole. Garbage collection still happens in Processing 1.5.1 but not in Processing 2.0b6.

From goo...@superduper.org on December 16, 2012 22:19:47
i don't agree that #5 should be considered a programming error.
loading images depending on user interaction is a quite common thing (for me at least)

#8 actually fixes it for me.

only took a rough look, what strikes me is that there's no awtImage.flush() when the image is loaded
http://code.google.com/searchframe#Ej56LtI_pY0/trunk/processing/core/src/processing/core/PApplet.java&l=5144
(maybe my oversight)

From f...@processing.org on December 16, 2012 23:21:33
No, you're completely mischaracterizing what I said. I said re-loading images inside draw(), which by default runs at 60 frames per second, is a programming error. That's never going to work properly, and is really bad practice.

Loading on user interaction is of course important, but if you need new images at 60 fps, you want a movie, or for the images to be loaded once inside setup(), then swapped in as necessary.

But the general fact that it runs out of memory is a really significant bug that I haven't had time to track down yet.

Hi, I've been experiencing a similar problem with using PShapes that has only been occurring in Windows 7. Works fine in Mac:

https://forum.processing.org/topic/pshape-memory-leak-in-windows#25080000002001447

Fixed in commit 3b64812

Hello,

I always have this memory leak issue in the 2.09 version, my code call in draw() :

this.cam.loadPixels();
PImage temp = this.cam.get(int((this.cam.width-this.widthGlitchedImage)/2), 0, int(this.widthGlitchedImage), this.cam.height);
temp.resize(this.widthDetectImage, this.heightDetectImage);
this.opencv.copy(temp);
g.removeCache(temp); // Out of memory withou this
this.faces = opencv.detect( 1.2, 2, OpenCV.HAAR_DO_CANNY_PRUNING, 20, 20);

Is-it relay fixed ?

Thanks

Yes, I also used version 2.0b9 and still have memory leaks with setupFrameResizeListener()

#1857

But this issue seems to be fixed in the 2.0 stable verions ! :)

The issue is fixed, please use the forum for further discussion.

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.