Memory Leak problem

Eggplant Functional
1

Eggplant FT Version4.12
VNC RealVNC 4.1.2 (Service Mode)
OS X
Version 10.5.3
Processor 2GHz Intel Core 2 Duo
Memory 1GB 667 MHz DDR2 SDRAM
I have two developer’s licenses running on my Mac.

I’ve been having some serious memory leak problem with Eggplant. I watched the Activity Monitor and the Virtual Memory goes up to 3.7GB(CPU-avg50, Threads-avg15, Real Memory-ard800MB) and then closes saying it closed unexpectedly. When it reaches around 2GB, my Mac lags so bad that it’s hard to even click anything.

This happens pretty randomly that I can’t find out where the memory leak is happening. If I get lucky, this might not happen. I usually had more luck with the older version of Eggplant 4.01.

The only way I could run the scripts without the memory leak reliably is to run it by the Apple script. This worked great even with the newer version of Eggplant. For some reason it says (Not Responding) in the Activity Monitor, but it still runs in the background.

I’ve been using Eggplant for around 2 years now and this is the first time it ever happened. Please help (

I’d love to show you all the codes, but then I gotta send the whole framework. And if there is something wrong with our code…shouldn’t this happen every time?

2

Jason:
At one point we had a fairly substantial leak as it related to the CaptureScreen command. I believe that is resolved in 4.12 but can you let us know if you are using that command?

3

I do use that command, but I never had problem with it so far. And this memory leak happens even before it hits any CaptureScreen cmd, so I don’t think that’s the problem.

4

It’s difficult without a bit more information. Is this usually just running a script? Are you editing or doing anything else at this time?

Do you make a lot of calls to establish connections with the Connect command?

5

We start running the script using the Start script in the Master folder. It basically just calls all the modules in the Helper and run it all.
So, it’s just running the script & reading & writing into files.

6

Is there anymore information I can provide to help you investigate? Please let me know if there is any progress…

7

There is a memory leak involving the use of chunk expressions in scripts that has been fixed in-house for the next release of Eggplant. Are you using a lot of chunk expressions in your scripts?

8

Yes, I use it everywhere in my scripts. Do you know the release date of the next version of Eggplant?

9

I found the problem!!! YES!
I had too many Helpers and Eggplant was searching too hard find the right scripts every time I called a class from a Helper.
I had my scripts set up like this

  • Master.suite had all the helpers like “Module01”, “Module02”, “Module03”…on and on and on. Each Module suites contains different kind of tests.
  • Each Module## suites has a script called “Run##.script”(## equals to the Module number).
  • Each Module suite has a Helper called Storage suite which I store all my functions & images.
  • Storage suite has a Helper called System suite which I store all the framework classes in.
  • System suite has Storage in the Helper.

I have my Start script in the Master suite which basically just runs “Run##.script” from 1 to whatever. Since this was causing so much lag, I got rid of all the helpers from my Master suite and ran the test by giving the full path. e.g. Run “/Volume/Eggplant Projects/Something.suite/Scripts/Module10/Run10”. Now it works perfectly fine. )

Is this a bug? or was I using it wrong? cuz I used it this way for 2 years and nothing like this ever happened. Hopefully, you guys will fix it for next release. :wink:

Thanks for your help.

10

Another option instead of using the full path to call the script would be to insert each module suite into the FinalSuites dynamically when you are ready to run the tests in that module, and then remove it afterward. Think of the FinalSuites as a dynamic list of helper suites that you control from your script. So in your Master script it would look something like this:

// run tests in Module01
insert "Module01.suite" after the FinalSuites
run "Run01"
delete the last item of the FinalSuites -- remove module01 from use

This gives you the advantage that suites offer of being able to store module-specific images in the suite for that module, and also to be able to call any other scripts in that suite while it is being used.

You could make this code more general, to run a sequence of modules like this:

set modulesToRun to ("01", "02", "06", "10", "23")

repeat with each module in modulesToRun
    set moduleSuite to "Module" & module & ".suite"
    insert moduleSuite after the FinalSuites
    run ("Run" & module)
    delete the last item of the FinalSuites
end repeat

As to the performance issues you mentioned, we’ll take a look into that when we get a chance. In the meantime it sounds like limiting the number of helper suites open at once has alleviated the problem for you. Thanks for posting a detailed description of your approach. That will help us to understand where we should focus our attention.

11

I just tried it with your FinalSuites method. Unfortunately, it causes same amount of lag as before. Only the full path method is working for me so far. /