Java heap space exhausted with long running script

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a method that waits for a image to appear and then clicks on a 
position using: 
mouse.click(foundTarget.getCenter().getRelativeScreenLocation(x, y));.
2. Run the method in a infinite loop

What is the expected output?
-A method that runs "forever"

What do you see instead?
-A mem usage in the task manager that increases every time the method is 
executed and eventually a crash with the following exception:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.awt.image.DataBufferByte.<init>(Unknown Source)
    at java.awt.image.ComponentSampleModel.createDataBuffer(Unknown Source)
    at java.awt.image.Raster.createWritableRaster(Unknown Source)
    at javax.imageio.ImageTypeSpecifier.createBufferedImage(Unknown Source)
    at javax.imageio.ImageReader.getDestination(Unknown Source)
    at com.sun.imageio.plugins.png.PNGImageReader.readImage(Unknown Source)
    at com.sun.imageio.plugins.png.PNGImageReader.read(Unknown Source)
    at javax.imageio.ImageIO.read(Unknown Source)
    at javax.imageio.ImageIO.read(Unknown Source)
    at org.sikuli.api.robot.desktop.DesktopScreen.getScreenshot(DesktopScreen.java:35)
    at org.sikuli.api.DefaultScreenRegion.capture(DefaultScreenRegion.java:126)
    at org.sikuli.api.ImageTarget.getUnordredMatches(ImageTarget.java:122)
    at org.sikuli.api.DefaultTarget.doFindAll(DefaultTarget.java:93)
    at org.sikuli.api.DefaultScreenRegion._find(DefaultScreenRegion.java:73)
    at org.sikuli.api.DefaultScreenRegion.access$0(DefaultScreenRegion.java:69)
    at org.sikuli.api.DefaultScreenRegion$RepeatFind.run(DefaultScreenRegion.java:110)
    at org.sikuli.api.DefaultScreenRegion.wait(DefaultScreenRegion.java:119)
    at OperationExecuter.CreateFastReport(OperationExecuter.java:30)
    at BMSVerifierClient.main(BMSVerifierClient.java:61)

What version of the product are you using? On what operating system?
-sikuli-api-1.0.2-standalone.jar running on Windows XP SP3 with Java Version 7 
Update 9

Please provide any additional information below.
-The problem is very similar to https://bugs.launchpad.net/sikuli/+bug/1013396

Original issue reported on code.google.com by johan.pa...@gmail.com on 23 Nov 2012 at 10:37

[GoogleCodeExporter]

Can you tell us how long your script typically runs before the heap space runs 
out? minutes or hours? thanks!

Original comment by pilyo...@gmail.com on 23 Nov 2012 at 1:46

[GoogleCodeExporter]

Roughly 10 minutes. At that time the process has consumed 300MB.

Original comment by johan.pa...@gmail.com on 23 Nov 2012 at 4:48

[GoogleCodeExporter]

Original comment by doubles...@gmail.com on 24 Nov 2012 at 1:41

• Changed state: Started

[GoogleCodeExporter]

Please try the latest snapshot jar:
http://code.google.com/p/sikuli-api/downloads/detail?name=sikuli-api-1.0.3-stand
alone-SNAPSHOT.jar

It has been tested on the following code for several hours successfully without 
a memory error. Please confirm it works fine on your code too.
{{{
ScreenRegion s = new DesktopScreenRegion();     
while (true){                       
    Target target = new ImageTarget(new File("large.png"));
    s.wait(target, 100);            
    s.findAll(target);      
}
}}}

Original comment by doubles...@gmail.com on 26 Nov 2012 at 1:41

• Changed state: Fixed

[GoogleCodeExporter]

My code has been running for more then 24h now and it seems to work as it is 
supposed to do, without any memory leaks. Thank you very much for the quick 
response!

Original comment by johan.pa...@gmail.com on 27 Nov 2012 at 8:01

[GoogleCodeExporter]

Hi! I have the same leak with 1.0.2, tried with 1.0.3 and seems to work fine.  
I checked out the source repository 
https://bitbucket.org/doubleshow/sikuli-api/ and found no commits releated with 
this issue. Can you explain the root cause of the leak? When are you planning 
to release officially this fix? (1.0.3 seems to be deprecated)

BTW, I think that the Issue#20 is similar to this one. 

Thanks in advance!
fef.-

Original comment by feferr...@gmail.com on 5 Feb 2013 at 8:36