Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 0 down vote favorite
1

When making my simple app for revisions to update the latest changes, I test it first between the device (Google Nexus 7) and desktop using Eclipse IDE. I made eleven screens for the game in terms of the following for testing:

  • Splash screen (usually the company's logo)
  • Game content (Usually announced if it's rated E or M, for example)
  • Loading Screen
  • Title screen
  • Main Menu screen
  • Player 1's registration screen
  • Player 2's registration screen
  • Player list screen
  • Game screen

I tried testing switching screen by running onto the desktop and it works without limits. However, on running device, every time I switched or went to the next screen the eighth time, The app suddenly returned back to the Android desktop menu as if the app closes without notifying an error message meaning that this app worked normally.

Was it has a gimmick or something that there is a memory leaking issues due to switching screens? The images went okay with 100% bad memory leaks issue free but switching screen is going limited now instead, compared to the desktop test. What can I do or suggest something?

Here's the first part why does the app suddenly shuts down without error notification. Take a look at this Logcat:

01-29 10:48:27.846: E/AndroidRuntime(11707):    at com.Bodapps.KinkyTime.Models.Images.Dispose_Images(Images.java:329)
01-29 11:02:27.636: I/dalvikvm-heap(12963): Grow heap (frag case) to 8.416MB for 790411-byte allocation
01-29 11:02:27.646: D/dalvikvm(12963): GC_CONCURRENT freed 0K, 12% free 8472K/9520K, paused 3ms+2ms, total 16ms
01-29 11:02:27.646: D/dalvikvm(12963): WAIT_FOR_CONCURRENT_GC blocked 13ms
01-29 11:02:27.646: D/dalvikvm(12963): WAIT_FOR_CONCURRENT_GC blocked 13ms
01-29 11:02:27.836: D/dalvikvm(12963): GC_CONCURRENT freed 1125K, 18% free 7819K/9520K, paused 2ms+1ms, total 17ms
01-29 11:02:27.916: D/dalvikvm(12963): GC_CONCURRENT freed 371K, 18% free 7865K/9520K, paused 2ms+2ms, total 17ms
01-29 11:02:27.976: D/dalvikvm(12963): GC_CONCURRENT freed 544K, 19% free 7768K/9520K, paused 1ms+1ms, total 16ms
01-29 11:02:27.976: D/dalvikvm(12963): WAIT_FOR_CONCURRENT_GC blocked 11ms
01-29 11:02:28.036: D/dalvikvm(12963): GC_CONCURRENT freed 384K, 18% free 7867K/9520K, paused 2ms+2ms, total 17ms

After I switched the screen the 6th or 7th time, the app closes due to memory leaks in LibGDX and here's the result:

01-29 11:10:58.546: I/dalvikvm-heap(13772): Grow heap (frag case) to 8.662MB for 790411-byte allocation
01-29 11:10:58.556: D/dalvikvm(13772): GC_CONCURRENT freed 0K, 20% free 8723K/10808K, paused 2ms+2ms, total 17ms
01-29 11:10:58.556: D/dalvikvm(13772): WAIT_FOR_CONCURRENT_GC blocked 15ms
01-29 11:10:58.556: D/dalvikvm(13772): WAIT_FOR_CONCURRENT_GC blocked 14ms
01-29 11:10:58.816: D/dalvikvm(13772): GC_CONCURRENT freed 1122K, 26% free 8066K/10808K, paused 1ms+2ms, total 34ms
01-29 11:10:58.886: D/dalvikvm(13772): GC_CONCURRENT freed 371K, 25% free 8111K/10808K, paused 2ms+3ms, total 21ms

Now, not all time that putting all the materials should be put at dispose() method and will work. I decided to put the disposals under in the IF-ELSE statement code for touch button functionality. It seems more promising to free more memory than relying on the dispose() method but the result ends like this:

01-29 11:05:22.076: A/libc(12963): Fatal signal 11 (SIGSEGV) at 0x653815c0 (code=1), thread 12985 (Thread-6635)

Is there any good way to free up memory so that switching from menu to menu will not be bothered?

share|improve this question
How are you switching your screens? – Panda Pajama Jan 25 at 6:14
I'm using LibGDX that implements screen. – David Dimalanta Jan 25 at 6:42
@PandaPajama , look at the updated question as of January 29, 2013. I added the Logcat info so that you can clearly see the problem. – David Dimalanta Jan 29 at 3:24
1  
Your logcat output appears incomplete. For example, in the first one, it shows the tail end of an exception in process 11707, then some GC logs from 12963. The second shows some GC logs from 13772. None of the GC messages indicate any sort of failure or problem -- those are normal messages from a Dalvik VM. There is no indication that you're running out of memory in the logs. The native crash in the 3rd set of output is interesting but you didn't include any of the registers or call stack. – fadden Jan 29 at 18:45
1  
The "force close" dialog is generally put up by the failing app itself, when a Java-language exception lands in the global default uncaught exception handler. In the event of a native crash, that's not possible and the app just disappears, but you will get a full crash trace in "logcat". Watch the logcat output as it scrolls by, and capture just the part that begins when you start the last screen transition before the crash and stops after the process is dead. The native stack backtrace may give you some idea of where things are going wrong. – fadden Jan 30 at 18:37
show 9 more comments

Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.