search

TrueBlueDrive / robotium

Automatically exported from code.google.com/p/robotium
0 stars 0 forks source link

ActivityUtils.activityStack memory leak #331

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I see that the size of activityStack in ActivityUtils keeps increasing when I'm 
running a test case that performs repeated operations. For example, when I 
rotate the screen back and forth several times, the size of 
ActivityUtils.activityStack increases. Although WeakReference is used and 
Activity objects will be garbage collected, the WeakRference objects will not. 
My test cases could exhibit significant memory usage increase due to this 
problem. Is this a bug or is this expected?

Original issue reported on code.google.com by tonywins...@gmail.com on 23 Sep 2012 at 2:45

GoogleCodeExporter commented 9 years ago 
Thanks for reporting this. Would it be possible for you to send me a sample app 
that exhibits this problem?

Original comment by renasr...@gmail.com on 25 Sep 2012 at 5:52

GoogleCodeExporter commented 9 years ago 
I'm using robotium 3.3, and I think it exists for all applications. Here's how 
to observe it:

1. Create a HelloWorld Android application in Eclipse.
2. Create an Android test project for it, and set up the following test case:
    while (true) {
        solo.setActivityOrientation(Solo.LANDSCAPE);
        solo.sleep(2000);
        solo.setActivityOrientation(Solo.PORTRAIT);
        solo.sleep(2000);
    }
3. Open DDMS to observe the Java heap size. You will see it increasing *very* 
slowly. After a few minutes, you can do a hprof dump and see there are a lot of 
instances of WeakReference. Then, if you inspect the incoming references to 
these WeakReference objects, you can see they are ultimately referenced by 
ActivityUtils.activityStack.

I think the problem is that ActivityUtils.activityStack does not mimic the real 
activity stack. Instead, the top few elements of ActivityUtils.activityStack 
sort of reflect the current activity stack.

Original comment by tonywins...@gmail.com on 25 Sep 2012 at 6:21

GoogleCodeExporter commented 9 years ago 
This issue existed on 3.3 but has been fixed in 3.4.1. Please try with the
latest version instead.

Original comment by renasr...@gmail.com on 25 Sep 2012 at 6:23

GoogleCodeExporter commented 9 years ago 
I just tried it, and the problem still exists. Can you point me to the code 
diffs that fix this problem?

Original comment by tonywins...@gmail.com on 25 Sep 2012 at 6:49

GoogleCodeExporter commented 9 years ago 
Before 3.4.1 there were still strong references to activities even after the 
weak reference objects had been created. That is not the case anymore. Now only 
weak references are kept and they are not responsible for keeping activities 
alive. This improvement has been confirmed by several people that had memory 
issues prior to 3.4.1. 

Have you analyzed the memory footprint of your application when doing rotation 
changes manually?

Original comment by renasr...@gmail.com on 25 Sep 2012 at 7:15

GoogleCodeExporter commented 9 years ago 
I'm NOT saying Activity instances are kept alive. It is the WeakReference 
instances that are kept alive. And of course, the String instances in 
activitiesStoredInActivityStack are also alive. Once they are added to the 
stack, they are never removed. I confirmed this using MAT to analyse the heap 
dump. You can do the same in 10 minutes if you are willing to.

If I don't use robotium, the problem does not exist.

Original comment by tonywins...@gmail.com on 25 Sep 2012 at 7:21

GoogleCodeExporter commented 9 years ago 
Ok, now I understand what you mean. This will be looked at and improved in the 
next release. I will let you know when the changes have been made so you can 
verify that the issue does not exist anymore.

Original comment by renasr...@gmail.com on 25 Sep 2012 at 7:24

GoogleCodeExporter commented 9 years ago 
Thanks again. The leak in activityStack has been fixed in Robotium 3.5.

Original comment by renasr...@gmail.com on 11 Oct 2012 at 5:12