★ TouchArcade needs your help. Click here to support us on Patreon.

Nasty bug in App Store version

11-23-2009, 04:09 PM
#1
Joined: Aug 2009
Location: San Francisco
Posts: 362
Send a message via Skype™ to micah
Nasty bug in App Store version

I've gotten reports that there's a bad bug in Skeleton Key 1.6, which is in the App Store right now, that causes the game to crash whenever you run out of lives (as opposed to submitting your high score to OpenFeint, or letting you continue at zero score).

This puzzled me, because I tested it several times, in all different possible ways, and I couldn't reproduce the bug. Then I deleted Skeleton Key off my device and got a copy from the App Store with a promo code, and then I could easily reproduce the bug. But obviously I couldn't run it in debug mode.

There's no reason why this should be happening, since I didn't change any of my code since I submitted to the App Store. So I'm not really sure what to do. Should I go ahead and submit a new binary to the App Store, without changing any of the game code that might have caused the crash, since it's not crashing for me when I test it? Was there just some fluke with the submission process that corrupted part of the binary and that's what's causing the crash, but resubmitting it will maybe fix it? Any suggestions?

--=] Insurgent Games website | twitter [=-
Cryptose (TA) - Skeleton Key (TA) - Skeleton Key HD (TA link) - Aeropack (TA)
11-23-2009, 04:17 PM
#2
Joined: Dec 2008
Posts: 439
Quote:
Originally Posted by micah View Post
I've gotten reports that there's a bad bug in Skeleton Key 1.6, which is in the App Store right now, that causes the game to crash whenever you run out of lives (as opposed to submitting your high score to OpenFeint, or letting you continue at zero score).

This puzzled me, because I tested it several times, in all different possible ways, and I couldn't reproduce the bug. Then I deleted Skeleton Key off my device and got a copy from the App Store with a promo code, and then I could easily reproduce the bug. But obviously I couldn't run it in debug mode.

There's no reason why this should be happening, since I didn't change any of my code since I submitted to the App Store. So I'm not really sure what to do. Should I go ahead and submit a new binary to the App Store, without changing any of the game code that might have caused the crash, since it's not crashing for me when I test it? Was there just some fluke with the submission process that corrupted part of the binary and that's what's causing the crash, but resubmitting it will maybe fix it? Any suggestions?
Are you using Xcode? Can you post the code that runs when you run out of lives?

You've made the new version available for 2.2.1. I'm pretty sure the problem is related to this. Other people have had similar problems in relation to making code compatible for 2.2.1.

When you run in Debug mode... check for warnings... it may run fine... but there may be a warning that says, "won't work on 2.2.1" or something to that effect...

11-23-2009, 04:31 PM
#3
Joined: Dec 2008
Posts: 180
I assume yes, but have you run the game in release mode? Some code might misbehave when optimized.

Wooden Labyrinth 3D - Apple Design Award winner!
Multitask Madness - test your brain, challenge your friends!
Need quality iPhone consulting or custom applications? Check out my company's website at Qvik.fi!
11-23-2009, 04:33 PM
#4
Joined: Jul 2009
Location: Zgrunturos and San Francisco
Posts: 595
Quote:
Originally Posted by micah View Post
I've gotten reports that there's a bad bug in Skeleton Key 1.6, which is in the App Store right now, that causes the game to crash whenever you run out of lives (as opposed to submitting your high score to OpenFeint, or letting you continue at zero score).

This puzzled me, because I tested it several times, in all different possible ways, and I couldn't reproduce the bug. Then I deleted Skeleton Key off my device and got a copy from the App Store with a promo code, and then I could easily reproduce the bug. But obviously I couldn't run it in debug mode.

There's no reason why this should be happening, since I didn't change any of my code since I submitted to the App Store. So I'm not really sure what to do. Should I go ahead and submit a new binary to the App Store, without changing any of the game code that might have caused the crash, since it's not crashing for me when I test it? Was there just some fluke with the submission process that corrupted part of the binary and that's what's causing the crash, but resubmitting it will maybe fix it? Any suggestions?
Hey Micah, you still have the .dSYM file for that build? If so, grab the crash logs to see where it is crashing. A few more things.

-Do you debug in Release mode at all? Or are you always running Debug? We usually run in Debug, but near the end we always run in Release.

-You maybe should make yourself an ad hoc build that is similar in settings to your App Store distribution build. You can then load this via XCode and see if you get the crash.

Go to where the basketball court and arcade go 1 on 1 with Hoops Madness!
11-23-2009, 05:03 PM
#5
Joined: Aug 2009
Location: San Francisco
Posts: 362
Send a message via Skype™ to micah
I've only been debugging in Debug mode, not Release mode. That's a good idea, I'll try it. I do still have the .dSYM file. How do I see the crash logs from it?

Also, the project doesn't have any warnings, nor does it spit out anything I don't tell it to the debug console when you lose all your lives. So it's nothing obvious.

Anyway, I'm going to try to test things in Release mode now. I'll tell you if I find anything.

--=] Insurgent Games website | twitter [=-
Cryptose (TA) - Skeleton Key (TA) - Skeleton Key HD (TA link) - Aeropack (TA)
11-23-2009, 05:30 PM
#6
Joined: Jul 2009
Location: Zgrunturos and San Francisco
Posts: 595
Quote:
Originally Posted by micah View Post
I've only been debugging in Debug mode, not Release mode. That's a good idea, I'll try it. I do still have the .dSYM file. How do I see the crash logs from it?

Also, the project doesn't have any warnings, nor does it spit out anything I don't tell it to the debug console when you lose all your lives. So it's nothing obvious.

Anyway, I'm going to try to test things in Release mode now. I'll tell you if I find anything.
Release mode is always a good idea. Just curious, when you do a distribution build, what target settings did you copy it from? If it is Release, then you don't know for "sure" (not that you ever can be quite 100%) what'll it'll do.

Crash logs you get one of two ways. When you hook up to Xcode, go to the organizer. It will load them their. Here is a killer thing Apple did that rocks ... you can get crash logs from users that crash. Just do a google search, it'll tell you how. When the user syncs with iTunes, crash logs are downloaded. Note that on hard unit crashes, there usually will be no crash log.

Oh, things like no warnings really don't tell you how sound a program is. Just that syntactically you were correct in your programming.

Go to where the basketball court and arcade go 1 on 1 with Hoops Madness!
11-23-2009, 05:47 PM
#7
Joined: Aug 2009
Location: San Francisco
Posts: 362
Send a message via Skype™ to micah
Quote:
Originally Posted by mobileben View Post
Release mode is always a good idea. Just curious, when you do a distribution build, what target settings did you copy it from? If it is Release, then you don't know for "sure" (not that you ever can be quite 100%) what'll it'll do.
Yeah, I copy from Release.

Quote:
Originally Posted by mobileben View Post
Crash logs you get one of two ways. When you hook up to Xcode, go to the organizer. It will load them their. Here is a killer thing Apple did that rocks ... you can get crash logs from users that crash. Just do a google search, it'll tell you how. When the user syncs with iTunes, crash logs are downloaded. Note that on hard unit crashes, there usually will be no crash log.
Good to know! Ok, I just installed an ad-hoc build and have reproduced the crash with it, and I have the crash log in hand too. Here's the thread that crashed:

Code:
Thread 0 Crashed:
0   libSystem.B.dylib             	0x00090b5c __kill + 8
1   libSystem.B.dylib             	0x00090b4a kill + 4
2   libSystem.B.dylib             	0x00090b3e raise + 10
3   libSystem.B.dylib             	0x000a7e64 abort + 36
4   libstdc++.6.dylib             	0x00066390 __gnu_cxx::__verbose_terminate_handler() + 588
5   libobjc.A.dylib               	0x00008898 _objc_terminate + 160
6   libstdc++.6.dylib             	0x00063a84 __cxxabiv1::__terminate(void (*)()) + 76
7   libstdc++.6.dylib             	0x00063afc std::terminate() + 16
8   libstdc++.6.dylib             	0x00063c24 __cxa_throw + 100
9   libobjc.A.dylib               	0x00006e54 objc_exception_throw + 104
10  CoreFoundation                	0x00095c7e +[NSObject doesNotRecognizeSelector:] + 106
11  CoreFoundation                	0x0001ab12 ___forwarding___ + 474
12  CoreFoundation                	0x00011838 _CF_forwarding_prep_0 + 40
13  SkeletonKey                   	0x0000add2 -[GSGame restartLevel] (GSGame.mm:449)
14  Foundation                    	0x0000dd94 __NSFireTimer + 136
15  CoreFoundation                	0x000574bc CFRunLoopRunSpecific + 2192
16  CoreFoundation                	0x00056c18 CFRunLoopRunInMode + 44
17  GraphicsServices              	0x0000436c GSEventRunModal + 188
18  UIKit                         	0x00003c28 -[UIApplication _run] + 552
19  UIKit                         	0x00002228 UIApplicationMain + 960
20  SkeletonKey                   	0x00003fa0 main (main.m:14)
21  SkeletonKey                   	0x00003f3c start + 44
It looks like GSGame.mm:449 is causing the problem. That line is:

Code:
[manager doStateChange:[GSGameOver class]];
This method changes Views, and this is switching to the GameOver view. Here's what doStateChange looks like:

Code:
- (void) doStateChange:(Class)state {
	BOOL animateTransition = TRUE;
	if(animateTransition) {
		[UIView beginAnimations:nil context:NULL];
		[UIView setAnimationDuration:0.5];
		[UIView setAnimationTransition:UIViewAnimationTransitionFlipFromLeft forView:window cache:YES];
	}
	if(viewController.view != nil) {
		[viewController.view removeFromSuperview]; // remove view from window's subviews
		[viewController.view release], viewController.view = nil; // release game state
	}
	viewController.view = [[state alloc] initWithFrame:CGRectMake(0, 0, IPHONE_WIDTH, IPHONE_HEIGHT) andManager:self];
	// now set our view as visible
    [window addSubview:viewController.view];
    [window makeKeyAndVisible];
	if(animateTransition) {
		[UIView commitAnimations];
	}
}
I'm still confused why this is causing this:

Code:
10  CoreFoundation                	0x00095c7e +[NSObject doesNotRecognizeSelector:] + 106
I'll keep working on it, but any insight? I'll try building this for OS 3.0 also, instead of 2.2.1, and see if that fixes it. I would still like 2.2.1 support of course, but I might do that as a last resort.

--=] Insurgent Games website | twitter [=-
Cryptose (TA) - Skeleton Key (TA) - Skeleton Key HD (TA link) - Aeropack (TA)
11-23-2009, 06:01 PM
#8
Joined: Dec 2008
Posts: 439
Do you have a prototype definition for doChangeState in your header file?
11-23-2009, 06:03 PM
#9
Joined: Dec 2008
Posts: 439
Quote:
Originally Posted by mobileben View Post
-You maybe should make yourself an ad hoc build that is similar in settings to your App Store distribution build. You can then load this via XCode and see if you get the crash.
This is a cool idea... I should have done this when I had my crash problem...
11-23-2009, 06:07 PM
#10
Joined: Jul 2009
Location: Zgrunturos and San Francisco
Posts: 595
Hmmm ... this may start to be getting out of my comfort zone. We do basically everything in C++ and OpenGl. So I'm not Obj-C and CG savvy.

As far as what I'm seeing here ...

Are you explicitly using selectors for any form of callbacks? I believe the animation stuff uses it implicitly. Based on a non-recognized selector ... my guess is an object is trying to call a selector, but that object does not have that selector being called? Or the object is whacked so it doesn't exist. Again. my caveat is I'm not an Obj-C person.

One possible way of brute force doing this is insert NSLogs all into your restartLevel routine ... find out which one is the last one that calls called before the game visits crash central ! This probably includes inserting the NSLogs into your doStateChange routine.

Sorry is it's not a ton of help. Just curious, in your code you use the BOOL animateTransition, but it is always true. Any reason for that?

Go to where the basketball court and arcade go 1 on 1 with Hoops Madness!