memory leak?

[GoogleCodeExporter]

I run my app for a few hours and memory runs out and terminates.

stacktrace:
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.MultiStateTarget.getUnordredMatches(MultiStateTarget.java:27)
at org.sikuli.api.DefaultTarget.doFindAll(DefaultTarget.java:93)
at org.sikuli.api.DefaultScreenRegion.findAll(DefaultScreenRegion.java:58)
...

In file DesktopScreen.java:35 sikuli source is:
InputStream is = new ByteArrayInputStream(os.toByteArray());
return ImageIO.read(is);

Sikuli is not closing the 'is' stream here around. Comment in 
ImageIO.read(InputStream input) says that:
"This method does not close the provided
InputStream after the read operation has completed
it is the responsibility of the caller to close the stream, if desired."

Is it closed elsewhere, it is intended as it is now or my memory leaks out 
elsewhere?

Original issue reported on code.google.com by miglecz on 19 Jan 2013 at 6:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I removed the code that uses the Canvas and the leak seems fixed. More 
experiment showed that it fills up the heap, GC can't help.

Runtime runtime = Runtime.getRuntime();
Canvas canvas = new DesktopCanvas();
ScreenRegion region = new DesktopScreenRegion();
for (;;) {
  canvas.addBox(region).display(0);
  canvas.clear();
  System.out.println("heap MB: " + (runtime.totalMemory() - runtime.freeMemory()) / 1024 / 1024);
}

Original comment by miglecz on 21 Jan 2013 at 7:50

[GoogleCodeExporter]

I have the same problem but I didnt use Canvas objects in my code. I tried 
closing the InputStream in DesktopScreen.getScreenshot(DesktopScreen.java:35) 
but nothing change. The heap grow up until OutOfMemory exception is throwed

Original comment by feferr...@gmail.com on 5 Feb 2013 at 6:22

[GoogleCodeExporter]

I have the same exact issue, heap grows up until I get OOM  I am using 
DesktopScreenRegion DesktopCanvas

Original comment by mbdiwa...@gmail.com on 21 Mar 2013 at 12:13

[GoogleCodeExporter]

This issue is fixed in unofficial version 1.0.3 
http://code.google.com/p/sikuli-api/downloads/detail?name=sikuli-api-1.0.3-stand
alone-SNAPSHOT.jar&can=1&q=

Original comment by feferr...@gmail.com on 21 Mar 2013 at 2:43

[GoogleCodeExporter]

I tried unofficial version 1.0.3, Issue doesnt seem to be fixed,with every 
execution it seems the heap grows, jvisualvm shows reference

java.awt.image.BufferedImage#22 4,380,150
java.awt.image.BufferedImage#19 4,380,150
java.awt.image.BufferedImage#17 4,380,150
java.awt.image.BufferedImage#15 4,380,150
java.awt.image.BufferedImage#13 4,380,150
java.awt.image.BufferedImage#10 4,380,150
java.awt.image.BufferedImage#8 4,380,150
java.awt.image.BufferedImage#6 4,380,150
java.awt.image.BufferedImage#4 4,380,150
java.awt.image.BufferedImage#1 4,380,150

Original comment by mbdiwa...@gmail.com on 2 Apr 2013 at 5:17

[GoogleCodeExporter]

We are investigating this issue. There seems to be a leak related to some 
libraries we use to draw on the screen. What was the code you used that 
generate this buffer overflow error?

Original comment by doubles...@gmail.com on 2 Apr 2013 at 4:33

[GoogleCodeExporter]

I have memory leak as well, but it disappeared after removing excesive calls to 
"new DesktopScreenRegion()". Now I create it only once and keep the reference 
for all operations that start on whole desktop screen.

Original comment by ale...@seznam.cz on 2 Apr 2013 at 10:52

[GoogleCodeExporter]

 public void LoginToApplicationWith(String userName, String password) throws MalformedURLException {
        desktopScreenRegion = new DesktopScreenRegion();
        desktopCanvas = new DesktopCanvas();
        desktopCanvas.addBox(desktopScreenRegion);
        desktopCanvas.display(3);
        userName = userName + "\t";
        ImageTarget imageTarget;
        imageTarget = new ImageTarget(new File((AGENT_USERNAME)));
        ScreenRegion fr = desktopScreenRegion.find(imageTarget);

        if(fr != null){
            ScreenRegion right = Relative.to(fr).right(50).getScreenRegion();
            mouse.click(right.getCenter());
            keyboard.type(userName);
            keyboard.type(password);
        }
        else
        {
            System.err.print("unable to find user");
        }

        Mouse m = new DesktopMouse();
        ImageTarget img = new ImageTarget(new File((AGENT_LOGIN1)));
        ScreenRegion login = desktopScreenRegion.find(img);
        if (login != null){
            m.click(login.getCenter());
        }else
        {
            System.err.print("Login is not enabled");
        }

    }

Original comment by mbdiwa...@gmail.com on 2 Apr 2013 at 11:08

[GoogleCodeExporter]

I would recommend upping this issue to a high priority. There is no work around 
for it. 

Original comment by jlgu...@gmail.com on 10 Jun 2013 at 5:40

[GoogleCodeExporter]

We will be releasing an update soon. We will definitely work on this memory 
leak issue. Thanks for your patience.

Original comment by doubles...@gmail.com on 10 Jun 2013 at 5:44

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

the same problem, looking forward a fix

Original comment by igets...@gmail.com on 13 Jun 2013 at 9:06

[GoogleCodeExporter]

This is a pre-release that contains memory leak fixes.
https://bitbucket.org/doubleshow/sikuli-api/downloads/sikuli-api.standalone-1.0.
3-Pre-1.jar
Please try and report back whether memory leak issue has been addressed. Thanks!

Original comment by doubles...@gmail.com on 13 Jun 2013 at 5:06

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by doubles...@gmail.com on 13 Jun 2013 at 8:04

• Changed state: Fixed

[GoogleCodeExporter]

Memory usage prior to fix was 256 MB/256 MB.  Using the updated JAR, memory 
usage is averaging out at 23 MB/ 256 MB.  The issue is fixed.  

Original comment by jlgu...@gmail.com on 17 Jun 2013 at 1:27