Author Topic: memory issues  (Read 8757 times)

Offline raft

  • quad
  • ******
  • Posts: 1993
    • View Profile
    • http://www.aptalkarga.com
memory issues
« on: October 15, 2010, 02:52:55 pm »
as my game evolves, i begun to run into memory issues. game itself runs ok, fits the budget, but these things typically happens after pressing home and returning back. see the exception below.

i guess this happens when jPCT tries to restore textures after a GL surface lost. i dispose the FrameBuffer, null the reference and call MemoryHelper.compact() before creating a new one.

what else can i do?

Code: [Select]
E/dalvikvm-heap( 6803): 131072-byte external allocation too large for this process.
W/OSMemory( 6803): External allocation of 131072 bytes was rejected
W/dalvikvm( 6803): threadid=15: thread exiting with uncaught exception (group=0x4001b178)
E/AndroidRuntime( 6803): Uncaught handler: thread GLThread 8 exiting due to uncaught exception
E/AndroidRuntime( 6803): java.lang.OutOfMemoryError
E/AndroidRuntime( 6803): at org.apache.harmony.luni.platform.OSMemory.malloc(Native Method)
E/AndroidRuntime( 6803): at org.apache.harmony.luni.platform.PlatformAddressFactory.alloc(PlatformAddressFactory.java:145)
E/AndroidRuntime( 6803): at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:67)
E/AndroidRuntime( 6803): at java.nio.ReadWriteDirectByteBuffer.<init>(ReadWriteDirectByteBuffer.java:51)
E/AndroidRuntime( 6803): at java.nio.BufferFactory.newDirectByteBuffer(BufferFactory.java:95)
E/AndroidRuntime( 6803): at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:71)
E/AndroidRuntime( 6803): at com.threed.jpct.GLRenderer.convertTexture(GLRenderer.java:754)
E/AndroidRuntime( 6803): at com.threed.jpct.GLRenderer.blit(GLRenderer.java:1265)
E/AndroidRuntime( 6803): at com.threed.jpct.GLRenderer.execute(GLRenderer.java:1661)
E/AndroidRuntime( 6803): at com.threed.jpct.FrameBuffer.blit(FrameBuffer.java:591)
E/AndroidRuntime( 6803): at raft.glgui.android.TexturePack.blit(TexturePack.java:256)

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
Re: memory issues
« Reply #1 on: October 15, 2010, 08:46:23 pm »
Pfffft... ??? No idea...does this happen all the time or just every now and then?

Offline raft

  • quad
  • ******
  • Posts: 1993
    • View Profile
    • http://www.aptalkarga.com
Re: memory issues
« Reply #2 on: October 15, 2010, 09:08:05 pm »
not all the time. for large levels this happens every first or second try. gives me the feeling that, for some reason System.gc() (MemoryHelper.compact) does not free the memory it should.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
Re: memory issues
« Reply #3 on: October 15, 2010, 09:15:32 pm »
I had similar issues when loading images with an already pretty filled memory...i never found a solution, because it seemed to happen randomly.
Might very well be, that the gc doesn't free native memory reliable or in a given time frame. Does a sleep for some seconds does any good?

Offline raft

  • quad
  • ******
  • Posts: 1993
    • View Profile
    • http://www.aptalkarga.com
Re: memory issues
« Reply #4 on: October 15, 2010, 09:33:17 pm »
i put a 2 sec sleep after disposing buffer and gc, and make gc again. didnt help, maybe very slightly..

FrameBuffer unloads all textures from GL context during dispose, right? i have textures which arent added to TextureManager (for blitting only), maybe they arent cleared from GL context  ???

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
Re: memory issues
« Reply #5 on: October 15, 2010, 09:48:29 pm »
The gl context is being destroyed anyway by the Activity. By definition, this has to free all resources used by this context. When disposing the buffer, it's already too late because the context is long gone at that time.
I could add some hack to unload all textures regardless of the TextureManager directly via the FrameBuffer that has to be called manually if needed. I'm not sure, that this will do any good though. I'm not at home ATM...i can add this on sunday.

Offline raft

  • quad
  • ******
  • Posts: 1993
    • View Profile
    • http://www.aptalkarga.com
Re: memory issues
« Reply #6 on: October 16, 2010, 09:03:35 pm »
i've tried adding blit-only textures to TextureManager too but didnt help..

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
Re: memory issues
« Reply #7 on: October 17, 2010, 09:36:17 pm »
I've uploaded a new version, please give it a try. It adds a method to FrameBuffer called freeMemory(). Try to call it in onPause/onStop/on... and see if that does any good.

Offline raft

  • quad
  • ******
  • Posts: 1993
    • View Profile
    • http://www.aptalkarga.com
Re: memory issues
« Reply #8 on: October 18, 2010, 12:11:42 pm »
i've put the call into both onPause and onStop but unfortunately didnt make a difference :(

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
Re: memory issues
« Reply #9 on: October 18, 2010, 12:24:01 pm »
I didn't really expect it to... :(

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
Re: memory issues
« Reply #10 on: October 18, 2010, 12:31:18 pm »
Does it manage to upload anything or does it fail right on the first texture?

Offline raft

  • quad
  • ******
  • Posts: 1993
    • View Profile
    • http://www.aptalkarga.com
Re: memory issues
« Reply #11 on: October 18, 2010, 12:57:00 pm »
i see some "mipmaps generated" logs before the crash. as i remember this was the same before freeMemory method


Code: [Select]
I/jPCT-AE (10248): Memory usage before compacting: 15342 KB used out of 17799 KB
D/dalvikvm(10248): GC freed 78 objects / 5208 bytes in 56ms
D/dalvikvm(10248): GC freed 2 objects / 48 bytes in 49ms
I/jPCT-AE (10248): Memory usage after compacting: 15338 KB used out of 17799 KB
D/dalvikvm(10248): GC freed 47 objects / 1880 bytes in 72ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 1ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 2ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 2ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 2ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 2ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 2ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 2ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 2ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 2ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 0ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 1ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 2ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 1ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 0ms
I/jPCT-AE (10248): Mipmaps generated by the GPU in 2ms
D/dalvikvm(10248): GC freed 140 objects / 1304552 bytes in 43ms
I/jPCT-AE (10248): Static references cleared...
D/dalvikvm(10248): GC freed 216 objects / 210152 bytes in 43ms
I/dalvikvm-heap(10248): Grow heap (frag case) to 21.275MB for 2097168-byte allocation
D/dalvikvm(10248): GC freed 0 objects / 0 bytes in 70ms
D/dalvikvm(   71): GC freed 1443 objects / 66600 bytes in 486ms
I/ActivityManager(   71): Process android.process.media (pid 10187) has died.
D/dalvikvm(  123): GC freed 4546 objects / 206952 bytes in 83ms
D/dalvikvm(  139): GC freed 952 objects / 36936 bytes in 91ms
E/dalvikvm-heap(10248): 131072-byte external allocation too large for this process.
W/OSMemory(10248): External allocation of 131072 bytes was rejected
W/dalvikvm(10248): threadid=15: thread exiting with uncaught exception (group=0x4001b178)
E/AndroidRuntime(10248): Uncaught handler: thread GLThread 8 exiting due to uncaught exception
E/AndroidRuntime(10248): java.lang.OutOfMemoryError
E/AndroidRuntime(10248): at org.apache.harmony.luni.platform.OSMemory.malloc(Native Method)
E/AndroidRuntime(10248): at org.apache.harmony.luni.platform.PlatformAddressFactory.alloc(PlatformAddressFactory.java:145)
E/AndroidRuntime(10248): at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:67)
E/AndroidRuntime(10248): at java.nio.ReadWriteDirectByteBuffer.<init>(ReadWriteDirectByteBuffer.java:51)
E/AndroidRuntime(10248): at java.nio.BufferFactory.newDirectByteBuffer(BufferFactory.java:95)
E/AndroidRuntime(10248): at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:71)
E/AndroidRuntime(10248): at com.threed.jpct.GLRenderer.convertTexture(GLRenderer.java:767)
E/AndroidRuntime(10248): at com.threed.jpct.GLRenderer.blit(GLRenderer.java:1280)
E/AndroidRuntime(10248): at com.threed.jpct.GLRenderer.execute(GLRenderer.java:1683)
E/AndroidRuntime(10248): at com.threed.jpct.FrameBuffer.blit(FrameBuffer.java:594)
E/AndroidRuntime(10248): at raft.glgui.android.TexturePack.blit(TexturePack.java:258)
E/AndroidRuntime(10248): at raft.glgui.android.TexturePack.blit(TexturePack.java:201)
E/AndroidRuntime(10248): at raft.glgui.android.AGLFont.blitString(AGLFont.java:190)
E/AndroidRuntime(10248): at raft.jumpy.android.JumpyActivity$MyRenderer.onDrawFrame(JumpyActivity.java:731)
E/AndroidRuntime(10248): at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1116)
E/AndroidRuntime(10248): at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:975)

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
Re: memory issues
« Reply #12 on: October 18, 2010, 01:01:26 pm »
I doubt it, but maybe setting Config.internalMipmapCreation=true does any good? Just in case that the drivers mipmap-generation just sucks...

Offline raft

  • quad
  • ******
  • Posts: 1993
    • View Profile
    • http://www.aptalkarga.com
Re: memory issues
« Reply #13 on: October 18, 2010, 01:08:49 pm »
unfortunately  :(

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12295
    • View Profile
    • http://www.jpct.net
Re: memory issues
« Reply #14 on: October 18, 2010, 01:28:06 pm »
That log lacks some lines that i would have expected to see there...what exactly are you doing in onPause/onStop and are you disposing the FrameBuffer before or after calling freeMemory()?