Memory leaks??? RunMobileApp and Imaging.Find...

HardyG · Post by **HardyG** » Sun Jun 07, 2015 1:44 pm

Hi,

I'm just playing around with Raonorex 5.3.2 to find out if it could be used for doing my long term Android testing with it. I'm using it on win 8.1 together with VmWare Workstation and Android-x86.
Got it running fine so far - excellent tool by the way! Good job, guys!!!

One thing keeping me from deciding for it is that there seems to be a memory leak in (re-)starting the app using RunMobileApp. I used ANTS Memory Profiler and can see each time I start and restart the app using RunMobileApp it consumes additionally round about 250k of memory. Also using KillProcess in between two starts does not help. If I'm not wrong the leakage is in Ranorex.Plugin.Mobile.Device.Channels.TcpNetworkChannel - but please cross check.

The Problem with this is, that I need to do long lasting, reapeating tests having multiple virtual devices on one host. To have unique starting conditions I need to restart the app every few minutes between each test multiplied by the amount of virtual machines. That causes a "out of memory" after some time.

Could you please be so kind telling me,
1. if I'm right that this is a bug?
2. if so if you could please solve it as soon as possible?
3. if meanwhile you could help me out with a work around for it if there is any?

Reproducing the issue is easy. Just use any instrumented Android app you want, start it several times using RunMobileApp. As toled above you may also use KillProcess in between. Use any tool you preferre to see the memory leak caused by it.

Thanks a lot and kind regards,
Hardy

P.S.: There seems to be another memory leak in Ranorex.Imaging.Find which is not releasing all ressources in your byte buffer (CoreChannel._bufferPool) when finished. Interesting is, that there seems to be no leak as long as both compared bitmaps are identical... I would like to use this function very often so this issue is even worse than the above one

P.P.S.: ...same applies for Validate.ContainsImage - I guess it's using the same methods... e.g. doing 4 validations like that adding 26 MB to the unmanaged memory consumption of Ranorex internal buffers...

Is anyone able to tell me, please, how to get rid of this again? is there any chance to tell Ranorex to clean up these internally allocated, unmanaged ressources?

PLEASE, HELP!!!

Post by **Support Team** » Wed Jun 10, 2015 2:55 pm

Hi HardyG,

Thank you for reporting this problem. I’ve already forwarded this issue to our responsible development team. They will analyze it in more detail.

In the meantime, I’d like you to contact me by email [email protected] to discuss the problem directly with you. Maybe we can also find a possible workaround until the source of this problem is located.

Thank you for your patience and your understanding.

Regards,
Markus (S)

HardyG · Post by **HardyG** » Wed Jun 10, 2015 6:21 pm

Hi Markus,

thanks a lot for your reply!

I brought the issue related to Validate.ContainsImage down to the following:
- The default implementation Validate.ContainsImage(ItemInfoFromRepo, BitmapFromRepo, ...) wasts memory because it seems to allocate it for the Images needed each time but is never releasing it. This can be worked around by alocating it manually before and disposing it manually afterwards. Not nice but possible.
- If the validation fails an exception is created which is containing disposable objects / images which never get disposed. Work around is to find this objects in the catch path disposing it manually.
Thired issue is related to the report. In several Situation it does screenshots to document the situation (so by Intention) but even if one is defining a report file this images are not disposed. You may get rid of it by switching the reporting off (what shouldn't be our Goal, should it?

).

This is not nice but this brought it down a little - still not enough for long term testing...

And also the other two issues (related to RunMobileApp and Ranorex.Imaging.Find) are still there and (at least for me) much more important than the "Validate.ContainsImage" issue Event though these may be connected...

Kind regards and many thanks for your support,
Hardy

HardyG · Post by **HardyG** » Thu Jun 11, 2015 8:56 am

Hi again,

so now I can confirm that the work around "Validate.ContainsImage" can also be used for "Ranorex.Imaging.Find" (if you can accept the backdraws).

What did I do:
The Ranorex recorder is giving you a simple code sniped if you do an image based validation:

Code: Select all

Validate.ContainsImage(repo.Apps.YourApp.RDrawableIcLauncherInfo, RDrawableIcLauncher_Screenshot1, RDrawableIcLauncher_Screenshot1_Options);

If you change it to something like that most (NOT ALL) memory leak issues are gone:

Code: Select all

const string AppName = "YourApp";
const string DeviceName = "YourDevice";
const string AppPath = "/mobileapp[@title='" + AppName + "' and @devicename='" + DeviceName + "']";
const string ElementPath = "/form[@title='YourActivity']";
//...
Ranorex.Report.Setup(ReportLevel.None, null, false, false); // Backdraw: This is switching of reporting!!!
//...
Ranorex.MobileApp YourApp;
Host.Local.TryFindSingle(AppPath, new TimeSpan(0,0,5), out YourApp);
Element YourActivity = TestApp.FindSingle(AppPath + ElementPath);
CompressedImage ci = YourApp_Screenshot1;
Imaging.FindOptions fo = RDrawableIcLauncher_Screenshot1_Options;
//...
try {
   Validate.ContainsImage(YourActivity, ci, fo);
} catch(ImageValidationException e) {
   Report.Info("Exception: " + e.Message);
   e = null;
}
//...
ci.Image.Dispose();
ci = null;
fo = null;
YourApp = null;
YourActivity = null;
//...
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

As stated already this is not nice but at lease a possible way. Don't forget, that you need to implement your own way to collect / document your results because reporting is disabled completely!

Where exactly which ressources are allocated and should be released within Ranorex I can't tell exactly.

For the remaining issue (the memory leak within RunMobileApp) I have no work around by now. Because with the above I'm now able to deal a work around for this remaining issue is urgently needed now!

Your help is very appreciated! Thanks a lot!
Kind regards,
Hardy

Post by **Support Team** » Thu Jun 11, 2015 12:52 pm

Hi Hardy,

Thank you for updating this post and for providing your workaround.

You should have received an email with further instructions. I'll update this posting as soon as we have found the source of this problem.

Thank you for your patience.

Regards,
Markus (S)

HardyG · Post by **HardyG** » Thu Jun 11, 2015 2:47 pm

Thanks a lot.
Yes, I've received your instructions.

Providing a sample won't help much I guess because devices and apps will differ for sure and won't help.
Just use any Android test setup available and any tool you usually use to find memory leaks. As of now I'm only using trial versions of Ranorex (5.3.2.23378) and ANTS Memory Profiler (8.6). As written earlier my DUT is Android-x86 on a VmWare Player but I'm pretty sure it'll be the same with real devices. I'm guessing you'll use your own setup.

As I said just any Android test setup already available will be sufficient, use the instructions (RunMobileApp, Ranorex.Imaging.Find , Validate.ContainsImage) under investigation (best case several times) and measure / analyze the memory consumption at start, in between and at the end and the memory leak will be immediately visible. Nothing more. These are native Ranorex instructions, nothing tricky, no complex code constructions or something. Just do the instructions and do the analysis with the tool of your choice.

As mentioned above at the moment a work around or solution for the "RunMobileApp" memory leak is most important for me.

Thanks again for your great support.
Kind regards,
Hardy

HardyG · Post by **HardyG** » Wed Jun 17, 2015 11:31 am

Do you have any update for me?

HardyG · Post by **HardyG** » Thu Jun 18, 2015 11:58 am

BTW:

It seems, that the memory leak in RunMobileApp is related to the not released memory (256.012 bytes) of the "receiveBuffer" in "Ranorex.Plugin.Mobile.Device.Channels.TcpNetworkChannel".

Is there any method/work around to get rid of it?

Kind regards,
Hardy

Post by **Support Team** » Thu Jun 18, 2015 2:01 pm

Hi Hardy,

Unfortunately we were not able to reproduce the memory leaks in connection with our Imaging methods.

Concerning the RunMobileApp

One of my colleagues from the QA department is currently in the process of analyzing this behavior on more detail. I'll update you as soon as I've got any additional information.

Thank you for your patience and your understanding.

Kind regards,
Markus (S)

HardyG · Post by **HardyG** » Mon Jun 22, 2015 8:30 am

Thanks a lot for your quick reply.
So I'm looking forward for your findings and Solutions.

even though... I'm a little surprised that you were not able to find the memory leaks in the Imaging methods... because they are realy obvious. I also provided some code in an earlier post... however These are not SO important - at least not to me - because I've already found work arounds for these also posted earlier

Post by **Support Team** » Tue Jun 30, 2015 8:38 am

Hi HardyG,

Our QA department found some discrepancies in relation to the RunMobileApp-method. They forwarded this behavior already to our responsible development team. One of my colleagues there will analyze the issue in more detail.
The QA department also checked the Imaging methods, but it seems that these methods do not contain a memory leak.
Thank you for your understanding and your patience.

Please let me know if you have any further questions.

Regards,
Markus (S)

HardyG · Post by **HardyG** » Tue Jun 30, 2015 7:51 pm

Good new! Excellent!
Thanks a lot, Markus.

Is there a work around for short term?
And are you able to tell me how I can find out in which release a bugfix for this will be released?

I can't 100% assure that also I did a mistake with the Imaging methods... Sorry if I provided missleading information. I was just convinced about but maybe I was wrong

Thanks again and kind regards,
Hardy

Post by **Support Team** » Fri Jul 03, 2015 9:43 am

Hi Hardy,

I'm afraid that there is currently no workaround available. Maybe you can increase the available memory if you are using a VM.

I can send you a notification and I'll also update this posting as soon as we were able to fix this issue or if I've received any news on it.

Should you have any further questions, feel free to contact us by email [[email protected]]. Thank you.

Regards,
Markus (S)

HardyG · Post by **HardyG** » Sat Jul 04, 2015 6:04 am

Dear Markus,

thanks again!

I'm already working on a setup having 32GB but my Ranorex solution is already craching at around 1.6GB (starting at a need of round about 200MB) - no clue why...
So I think increasing the memory wont help much. I guess I'll have to wait for the bugfix - that's hard. Time is money you know

A notification would be great.

Kind regards,
Hardy

HardyG · Post by **HardyG** » Mon Jul 27, 2015 7:40 am

Hi Markus,

is there any update on this one?

Kind regards,
Hardy

Ranorex Forum

Memory leaks??? RunMobileApp and Imaging.Find...

Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...

Re: Memory leaks??? RunMobileApp and Imaging.Find...