AliSherKashif / codenameone

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

Memory Leak #610

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hi

I'm developing an application that has a form that should work as a Facebook 
wall. I'm using the pull to refresh feature to add components to this form. The 
problem is that when I exit the form, or even when clearing the form components 
manually on the fly, the memory allocated so far remains allocated and it seems 
is never released.
This is causing a continous RAM usage increase over the time (no much time) 
until the point the system kills the process to avoid a system crash.

This is happening as far as I've tested, from Android 4+. I ran a test on an 
old galaxy tab with Android 2.2 and it seems this not happens, or at least the 
memory allocation is very low per component that I cannot observe a huge RAM 
usage increase over a few minutes. Running the test on Android 4+ (galaxy s3 
stock rom and AOKP JB custom rom) causes a fast increase on RAM allocation 
(maybe related to the theme) and never gets released.

With the attached project
1. On the first screen just press the first button (no data required)
2. On the second screen just press the first button (Man icon)
3. On the third screen just pull to refresh to begin adding components. Be 
aware that I've detected a random NullPointerException on this feature, maybe a 
collision between the pull animation and adding components, so try to not pull 
so fast. Add 30+ components, so pull 30+ times for a noticeable RAM increase.
4. Press the back key to discard the form.
5. Realize no RAM was deallocated, or it was too little compared to the actual 
RAM allocated by this process.
6. Enter again the third screen (step 2) without closing the application and 
proceed with step 3, 4, 5 again. You'll see RAM just increasing and never 
decreasing. If you repeat this long enough, the device will run out of memory 
and the system will terminate the application.

*************************************
Sample Project
*************************************

Uploaded to mediafire as is too big for attachment:
http://www.mediafire.com/download.php?wpa509au1z4b94a

It's a very simple project so far but is very close to what I need to achieve.

I've created a simple navigation controller based on "Places", This is 
implemented in the Place and PlaceManager classes.
A place is basically module of the application that may contain a form. It has 
a simple lifecycle management (launched, resume, pause, finish). A place is 
stacked by a PlaceManager, which is responsible for calling the lifecycle 
methods and to pop and push places from a stack. It's very simple, just a few 
lines of code. I've checked and the lifecycle is being managed correctly and 
the stack size is consistent with this,

And then there are three places implementations: 
PL_Home: the main place. The first button on screen launches the wall place
PL_Login: dummy login, no data needed, just press the first button.
PL_Wall: empty at first but implements the pull to refresh feature to add 
components.

Original issue reported on code.google.com by manuell...@gmail.com on 23 Mar 2013 at 3:59

GoogleCodeExporter commented 9 years ago
Can you just remove the jars from the project and upload here? Thanks.

Original comment by shai.almog on 23 Mar 2013 at 4:07

GoogleCodeExporter commented 9 years ago

Original comment by shai.almog on 23 Mar 2013 at 4:07

GoogleCodeExporter commented 9 years ago
Here it is

Original comment by manuell...@gmail.com on 23 Mar 2013 at 4:12

Attachments:

GoogleCodeExporter commented 9 years ago
I played with this a lot on a galaxy nexus and can't seem to reproduce any such 
memory growth that leads to a crash. I do see GC taking effect and removing the 
images/data from RAM. 
Can you see this issue reproduces for you without the pull to refresh feature 
(just add a button to add the elements). Then see if you can reproduce 
something like this by just adding plain buttons without the UIBuilder code you 
wrote. This way we can pinpoint what is the source of the problem. Its possible 
that Samsung's custom skin is leaking texture data in their GPU acceleration.

Original comment by shai.almog on 24 Mar 2013 at 7:55

GoogleCodeExporter commented 9 years ago
Hi, Sorry for the delay
Yes I did a test to discard the pull to refresh a the cause, so I made a 
version that loads 30 components just at the moment the form opens and 
something interesting happened.

When I load the form, just one or two components ar visible, the rest is 
offscreen. When I don't scroll down, the memory don't seem to grow that much (I 
assume is a rendering optimization to not load reaosurces that are not being 
rendered). The memory starts to increase when I scroll down the form. However, 
after scrolling and closing and opening the form several times, the behavior is 
the same I mentioned, memory keeps allocated.

The same happened with a test for adding just buttons, created from code. In 
this case is takes a longer time to produce a significant memory growth and It 
seems to behave in the same way. I could extrapolate the same result but in 
this case I'm not pretty sure as I didn't get the test that far.

Do you have a chance to test this application on a galaxy s3? How did you 
realize that the images/data was removed from RAM? 

Original comment by manuell...@gmail.com on 28 Mar 2013 at 6:10

GoogleCodeExporter commented 9 years ago
I didn't test it on an S3 because I don't have access to that device. On a 
Galaxy Nexus device which is pretty similar I don't see any growth in RAM that 
isn't reverted when we leave the form.

Original comment by shai.almog on 28 Mar 2013 at 8:07

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I'll try making some tests on the emulator for various android version. I'll 
post the results later

Original comment by manuell...@gmail.com on 28 Mar 2013 at 3:59

GoogleCodeExporter commented 9 years ago
Closing the issue as part of cleanup due to lack of activity.

Original comment by shai.almog on 22 Nov 2013 at 8:42