Memory leak using AutomatedRunnable

Help
Anonymous
2010-04-02
2013-02-18
  • Anonymous - 2010-04-02

    Hello,

    I'm using the third party API specification (ApplicationSupport and ApplicationSupport) in order to execute native language test scripts sequentially inside my Java application.

    the code looks like this:

    ApplicationSupport robot = new ApplicationSupport();
    do
    {
    System.out.print("Insert Test script file name :");

    try {
    script_filename = myInput.readLine();
    } catch (IOException e) {
    System.out.println ("Error reading file name: " + e);
    System.exit(-1);
    }

    String args1 = { "-c", "192.168.2.206", "-p", "password", "-n", "-r", script_filename };

    AutomatedRunnable runnable1 = robot.createAutomatedRunnable("cli-1", args1, System.out, false);

    Thread t1 = new Thread(runnable1);

    t1.start();

    try {
    t1.join();
    } catch (InterruptedException e) {
    e.printStackTrace();
    }
    }
    while (script_filename != "exit");

    Every execution of this cycle performs a memory leak, not recoverable using garbage collector, till max size of Heap memory is reached and a outOfMemory exception is raised.

    Is it something wrong in using API in such a way? Can memory leak depends from script content?

    Thanks

     
  • Robert Pes

    Robert Pes - 2010-04-09

    The way you call it is generally correct. There must be a memory leak in the code though it is not obvious where because the runnables are not cached anywhere.

    The largest chunk of memory is always taken by the RFB client which stores internally the desktop image. I checked the client code and found out that even if it gets disconnected it doesn't set the image reference to null. Such a behavior would not resolve the leak completely but it would at least limit it to much smaller scope. I'll review whether this can be changed.

    A complete review and performance/profiling check must be performed to find the leak and fix it completely. This will take some time.

     
  • Robert Pes

    Robert Pes - 2010-04-27

    The memory leak was identified, fixed and the code was committed to CVS. I tested the interface through repeated test script execution and the tool didn't run out of memory even after 5000 executions. For comparison: before fix it crashed after 54 executions.

    If you are building from the source just refresh from CVS and rebuild. Otherwise wait for another release.

     
  • Anonymous - 2010-05-03

    Thanks, I will try it as soon as possible,and I'll give you some feedback!

     
  • Robert Pes

    Robert Pes - 2010-07-12

    The memory leak fix was released in 2.0.5.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks