Game Crashes - Any Thoughts?

Cluv

My game crashes on one of its levels and it seems to do it after I spawn a certain number of actors. However, I am constantly creating and destroying actors in my app, so I am uncertain as to what might be causing it. I noticed that the memory slowly leaks up and up until it crashes. Does anyone else have a similar issue?:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_c.dylib 0x358c8a80 memmove$VARIANT$CortexA9 + 240
1 MathMoney 0x000294de 0x1000 + 165086
2 MathMoney 0x0001c5ea 0x1000 + 112106
3 MathMoney 0x00021326 0x1000 + 131878
4 MathMoney 0x000211c8 0x1000 + 131528
5 MathMoney 0x0002119a 0x1000 + 131482
6 MathMoney 0x00023068 0x1000 + 139368
7 MathMoney 0x00018f7a 0x1000 + 98170
8 MathMoney 0x00014f08 0x1000 + 81672
9 MathMoney 0x000189fc 0x1000 + 96764
10 MathMoney 0x0001911a 0x1000 + 98586
11 MathMoney 0x00014ee0 0x1000 + 81632
12 MathMoney 0x00028fc0 0x1000 + 163776
13 MathMoney 0x00025faa 0x1000 + 151466
14 MathMoney 0x00027024 0x1000 + 155684
15 MathMoney 0x000262d8 0x1000 + 152280
16 QuartzCore 0x37af706c CA::Display::DisplayLink::dispatch(unsigned long long, unsigned long long) + 156
17 QuartzCore 0x37af6fc4 CA::Display::IOMFBDisplayLink::callback(__IOMobileFramebuffer*, unsigned long long, unsigned long long, unsigned long long, void*) + 60
18 IOMobileFramebuffer 0x3312dfd4 IOMobileFramebufferVsyncNotifyFunc + 152
19 IOKit 0x33132446 IODispatchCalloutFromCFMessage + 190
20 CoreFoundation 0x382f45d8 __CFMachPortPerform + 116
21 CoreFoundation 0x382ff170 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32
22 CoreFoundation 0x382ff112 __CFRunLoopDoSource1 + 134
23 CoreFoundation 0x382fdf94 __CFRunLoopRun + 1380
24 CoreFoundation 0x38270eb8 CFRunLoopRunSpecific + 352
25 CoreFoundation 0x38270d44 CFRunLoopRunInMode + 100
26 GraphicsServices 0x3a41d2e6 GSEventRunModal + 70
27 UIKit 0x388e92fc UIApplicationMain + 1116
28 MathMoney 0x0002c1ba 0x1000 + 176570
29 MathMoney 0x000038f4 0x1000 + 10484

Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib 0x3a37a648 kevent64 + 24
1 libdispatch.dylib 0x35b4f974 _dispatch_mgr_invoke + 792
2 libdispatch.dylib 0x35b4f654 _dispatch_mgr_thread$VARIANT$mp + 32

Thread 2 name: WebThread
Thread 2:
0 libsystem_kernel.dylib 0x3a379eb4 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x3a37a048 mach_msg + 36
2 CoreFoundation 0x382ff040 __CFRunLoopServiceMachPort + 124
3 CoreFoundation 0x382fdd9e __CFRunLoopRun + 878
4 CoreFoundation 0x38270eb8 CFRunLoopRunSpecific + 352
5 CoreFoundation 0x38270d44 CFRunLoopRunInMode + 100
6 WebCore 0x3a480a70 _ZL12RunWebThreadPv + 440
7 libsystem_c.dylib 0x358b930e _pthread_start + 306
8 libsystem_c.dylib 0x358b91d4 thread_start + 4

Thread 3 name: com.apple.NSURLConnectionLoader
Thread 3:
0 libsystem_kernel.dylib 0x3a379eb4 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x3a37a048 mach_msg + 36
2 CoreFoundation 0x382ff040 __CFRunLoopServiceMachPort + 124
3 CoreFoundation 0x382fdd9e __CFRunLoopRun + 878
4 CoreFoundation 0x38270eb8 CFRunLoopRunSpecific + 352
5 CoreFoundation 0x38270d44 CFRunLoopRunInMode + 100
6 Foundation 0x360b1bc8 +[NSURLConnection(Loader) _resourceLoadLoop:] + 304
7 Foundation 0x36135678 __NSThread__main__ + 968
8 libsystem_c.dylib 0x358b930e _pthread_start + 306
9 libsystem_c.dylib 0x358b91d4 thread_start + 4

Thread 4 name: com.apple.CFSocket.private
Thread 4:
0 libsystem_kernel.dylib 0x3a38a594 __select + 20
1 CoreFoundation 0x383031f2 __CFSocketManager + 674
2 libsystem_c.dylib 0x358b930e _pthread_start + 306
3 libsystem_c.dylib 0x358b91d4 thread_start + 4

Thread 5 name: AURemoteIO::IOThread
Thread 5:
0 libsystem_kernel.dylib 0x3a379eb4 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x3a37a048 mach_msg + 36
2 AudioToolbox 0x3b682624 AURemoteIO::IOThread::Run() + 104
3 AudioToolbox 0x3b68498c AURemoteIO::IOThread::Entry(void*) + 4
4 AudioToolbox 0x3b5c28a2 CAPThread::Entry(CAPThread*) + 294
5 libsystem_c.dylib 0x358b930e _pthread_start + 306
6 libsystem_c.dylib 0x358b91d4 thread_start + 4

Thread 6 name: AQClient
Thread 6:
0 libsystem_kernel.dylib 0x3a379eb4 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x3a37a048 mach_msg + 36
2 CoreFoundation 0x382ff040 __CFRunLoopServiceMachPort + 124
3 CoreFoundation 0x382fdd9e __CFRunLoopRun + 878
4 CoreFoundation 0x38270eb8 CFRunLoopRunSpecific + 352
5 CoreFoundation 0x38270d44 CFRunLoopRunInMode + 100
6 AudioToolbox 0x3b5e15b6 GenericRunLoopThread::Entry(void*) + 134
7 AudioToolbox 0x3b5c28a2 CAPThread::Entry(CAPThread*) + 294
8 libsystem_c.dylib 0x358b930e _pthread_start + 306
9 libsystem_c.dylib 0x358b91d4 thread_start + 4

Thread 0 crashed with ARM Thread State (32-bit):
r0: 0x00000000 r1: 0x07917a88 r2: 0xffffffc8 r3: 0xc62e90ce
r4: 0x00000000 r5: 0x07917a80 r6: 0x00000000 r7: 0x2fdfeb48
r8: 0x00000008 r9: 0x00007a00 r10: 0x00000008 r11: 0x00939640
ip: 0x00000000 sp: 0x2fdfeb40 lr: 0x000294e3 pc: 0x358c8a80
cpsr: 0x600f0010

famekrafts

Spawning actors and destroying them is bad workflow.

Try to make your game screen double width, and put all the actors on the right out of the camera side and simply call them when needed and send them off screen when job is done, with move or interpolate or constrain attributes.

I am also stuck with scrolling background part of my game with this. I am not sure hows its going to work on ipad, haven't tested yet.

Cluv

@wickedsunny: Why is it bad workflow to spawn and destroy actors? I would think that keeping actors on screen that are not being referenced is a waste of memory. Could you elaborate?

famekrafts

I read in other threads that spawning and destroying actors can cause memory leak.

It totally depends on your game project, if you are making a puzzle or a game with tiles system, its will actually save some memory because that particular tile will be loaded in memory instead of assigning new memory to it.

I am not sure how it all works, just got my apple D license today, so soon going to try out and check which works best.

Cluv

I hear you. I see where it is leaking and it frustrates me to know end! I think I will try your suggestion and go from there. Thanks!

Cluv

Bump - New Info:

The crash/leak is being caused by turning on the physics on the object. If the physics are off, I have no problem. I have also turned off all functions inside the object so it is definitely caused by the objects themselves. The .pngs are twice as large as necessary for resolution independence. Anyone else dealing with a similar problem?

Cluv

Edit:

So I set all the physics options to 0 and that seemed to slow down the leak significantly. That is OK for the time being, but I want to make sure I can use the physics attributes if I want to. Anyone clued in to the problem?

The_Gamesalad_Guru

Reduce the size of the images as it is using the amount of ram needed for the original size. When you scale an object in GS it doesn't scale it memory wise. Scale the images properly and be sure they are 72dpi as well as this can cause problems too.

MotherHoose

@Cluv

it is not memory … it is its memory allocation
i.e. the address in memory … the bytes location set to store the data of the actor

IMO
each spawn in a scene will allocate bytes to store each an instance of an actor
destroying the actor does NOT clean out the memory and free up those bytes
… it merely removes the actor from screenDisplay
each new spawn will generate a new location for bytes in memory

to clear memory of useless data and free it up for more stuff …
one needs a good garbage collection method … Lua's doesn't do that well
==
offScreen … recycling actors each only need one instance of memory allocation
much more efficient and faster … especially if Preload Art is unchecked

MH

The_Gamesalad_Guru

Most crashes are caused by code that fails to complete it's execution as ios6 is very sensitive to hangs. I've never had memory problems with my stuff even when spawning. It usually bad code in my experience.

Cluv

@motherhoose: thanks for the info on memory allocation. It is much appreciated! Hopefully lua free will help. Currently I reload the scene after a certain number of problems and this effectively resets the memory allocation back to baseline, but while the scene is running it leaks. Ah!

@fryingbaconstudios: I am in total agreement with your assessment about bad code, but when the leak still happened when I shut all my functions off in the object, that made me really wonder. It is directly linked to the number of physics attributes I use. I don't use any, no leak. 1, a little leak. 2, more, etc.

As for making the images smaller, in my iPhone version the images are substantially reduced, but the issue remains.

And, if I remove the object entirely, no leak!

I know I am not the most elegant coder, but I am certainly not the worst. I am at a loss for how the leak could be so significant when all I have are physics variables on.

I am sure I am probably coming across stubborn, and I really appreciate the suggestions, but could it be caused by anything else in my code?

Could it be if there is any transparency in my .png, that my cause extra memory to be allocated? Or, can I manually do a collide that circumvents gamesalad's one?

~ On a side note ~ I have removed enough of the physics variables to "fix" the problem for the time being. This discussion is more academic at this point and I really want to know what might be causing it. I will probably create a project that only has the object and nothing else and see what happens.

SolarPepperStudios

It definitely has something to do with the graphics because your crash includes the following core graphic threads:

16 GraphicsServices 0x3a41d2e6 GSEventRunModal + 70

17 QuartzCore 0x37af706c CA::Display::DisplayLink::dispatch(unsigned long long, unsigned long long) + 156

26 QuartzCore 0x37af6fc4 CA::Display::IOMFBDisplayLink::callback(__IOMobileFramebuffer*, unsigned long long, unsigned long long, unsigned long long, void*) + 60

At least it should...

Cluv

@Utveckla_Games : I was thinking that maybe it was the transparency in the .PNG or a bad size choice. Thanks for taking a look! Let me see if changing anything there fixes the issue.

The_Gamesalad_Guru

Is the object the same image?

Cluv

I use a table to generate which image the object uses based on the level. All the images are the same size, shape. In the iPad version each one is 100x100 pixels and are reduced from 200x200 for resolution independence. For the iPhone version I went ahead and reduced the .png size of the objects instead of using the overscanning to save memory (in general) and it upped the speed of my iPhone version considerably. But, all objects are the same image. The objects change to numbers during a "counting" phase in the program, but doesn't positively or negatively affect the leak as far as I can tell.