I run my little test (as I have posted in another thread here) on my Android, and after a while, I see that memory used by the program is growing forever.
I just let it run for 5 minutes or so, and the system shows that memory usage of this little test (which does almost nothing) is around 40MB. I let it run again, and it continues to grow.
Something's wrong. Is there a known memory leak?
Thanks for any help.
Paul
Memory use grows forever on Android!
-
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
-
- Posts: 16
- Joined: Wed May 04, 2011 12:30 pm
The draw loop is like this, which is copied from the tutorial:
I didn't add anything new to that, so I don't see how. The codes for the whole program are in my other post.
Code: Select all
void Java_com_test_TestIrrActivity_nativeDrawIteration( JNIEnv* env )
{
__android_log_print(ANDROID_LOG_INFO, "TestIrr", "nativeDrawIteration() called");
device->run();
if (counter == 0)
init();
driver->beginScene(true, true, SColor(255,100,101,140));
smgr->drawAll();
guienv->drawAll();
driver->endScene();
counter++;
int fps = driver->getFPS();
__android_log_print(ANDROID_LOG_INFO, "TestIrr", "TestIrr fps=%d", fps);
}
-
- Posts: 16
- Joined: Wed May 04, 2011 12:30 pm
-
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
Something which gets updated every frame (a scenenode, an animator, etc.) could be allocating memory each frame without freeing it, you should try to localize it immediately since these kind of leaks are rather severepverlaine999 wrote:I verified again with the example from the Irrlicht Android port, and it is the same code. I don't understand how memory use continues to grow like this.
Could someone give a hint on that?
Thanks
Paul
Is the counter variable ever used? Because your incrementing it every draw, although this probably isn't your problem I'd still switch it to something else. I'm guessing it's either a global or static variable, so something like:
But as Radikalizm said you should start commenting things out until it stops, then the last thing you commented was the cause, then narrow that down.
Also I had a problem recently where a resource was corrupted, but the program would load it and use it just fine, but the memory would continue to grow. Strangest thing I every saw, but as soon as I took out that resource and used a different one everything worked fine. But by the looks of this code your not loading any resources... Just thought I'd throw it out there though.
Another thing that sticks out to me is the log file, is it loaded into memory? Because when log files get longer they get bigger, try commenting out the log file bit and see what that does. It's more than likely not the cause, but it never hurts to comment those two lines just to make sure.
Goblin
Code: Select all
//Before Loop
static bool initialized=false; //Could be global instead of static
//In Loop
if(!initialized)
{
init();
initialized=true;
}
Also I had a problem recently where a resource was corrupted, but the program would load it and use it just fine, but the memory would continue to grow. Strangest thing I every saw, but as soon as I took out that resource and used a different one everything worked fine. But by the looks of this code your not loading any resources... Just thought I'd throw it out there though.
Another thing that sticks out to me is the log file, is it loaded into memory? Because when log files get longer they get bigger, try commenting out the log file bit and see what that does. It's more than likely not the cause, but it never hurts to comment those two lines just to make sure.
Goblin
I looked at your code again, it looks right, but it also looks wrong at the same time. It depends on how you run your application, because of the way Android pauses and resumes applications.
If you study Irrlicht by reading the tutorials, and try to port it to Android, there's something you need to watch out, i.e. the Android pause and resume mechanism.
According to the codes you showed in your post, this is what could happen:
If you run your application once, there should be no memory leak.
Now, if you run your application, and switch to another application while the Irrlicht application is running, Android will temporarily pause your Irrlicht app. If you haven't killed it (I mean, kill the process, not just lower the process window in the Android process stack by pausing it), and you start it again, Android will just resume your application, which was paused earlier.
When Android resumes your application, the onSurfaceCreated() method of your TestIrrRenderer will be invoked, and then the onDrawFrame() will be invoked as the loop goes on. And guess what this does? Looking at your code, onSurfaceCreated() calls nativeInitGL(), and in there, you just re-initialize everything again, without cleaning up the resources that you had initialized earlier. That's where your memory leak happens.
That's why I said you code looks right, but it looks wrong at the same time. The C code looks ok, but when you take the Android process flow into consideration, it is wrong.
I'm not sure how you run your application, and how you figure out that memory leak, but that's a problem that I'd look into.
Hope that helps.
If you study Irrlicht by reading the tutorials, and try to port it to Android, there's something you need to watch out, i.e. the Android pause and resume mechanism.
According to the codes you showed in your post, this is what could happen:
If you run your application once, there should be no memory leak.
Now, if you run your application, and switch to another application while the Irrlicht application is running, Android will temporarily pause your Irrlicht app. If you haven't killed it (I mean, kill the process, not just lower the process window in the Android process stack by pausing it), and you start it again, Android will just resume your application, which was paused earlier.
When Android resumes your application, the onSurfaceCreated() method of your TestIrrRenderer will be invoked, and then the onDrawFrame() will be invoked as the loop goes on. And guess what this does? Looking at your code, onSurfaceCreated() calls nativeInitGL(), and in there, you just re-initialize everything again, without cleaning up the resources that you had initialized earlier. That's where your memory leak happens.
That's why I said you code looks right, but it looks wrong at the same time. The C code looks ok, but when you take the Android process flow into consideration, it is wrong.
I'm not sure how you run your application, and how you figure out that memory leak, but that's a problem that I'd look into.
Hope that helps.
-
- Posts: 16
- Joined: Wed May 04, 2011 12:30 pm
Ah thank you very much, you made my day. This is exactly the problem. I put a flag to check the initialization, and that' s it, no more infinite memory growth.
But then, another problem props up. After the game is stopped and resumed, the graphic is not right. It looks like there's no texture applied. I can't really explain the problem, but the graphic looks more like an over-exposed photo (highly over-exposed). It's impossible to see the contour.
I'll look into this. But if someone knows what is going one, please give a hint. I tried the samples apps provided in the Irrlicth Android port, and it has exactly the same problem.
But then, another problem props up. After the game is stopped and resumed, the graphic is not right. It looks like there's no texture applied. I can't really explain the problem, but the graphic looks more like an over-exposed photo (highly over-exposed). It's impossible to see the contour.
I'll look into this. But if someone knows what is going one, please give a hint. I tried the samples apps provided in the Irrlicth Android port, and it has exactly the same problem.