Apple has approved our first app that has In-App Purchases - however suddenly when a user taps the "Upgrade" button the app hangs momentarily and then crashes. By using the Console feature in XCode's Organizer I was able to obtain the following report:
Sep 18 15:12:48 iPad MyApp[53107] <Error>: *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayI objectAtIndex:]: index 0 beyond bounds for empty array'
*** First throw call stack:
(0x316f92a3 0x3958497f 0x31643e8d 0x54b23 0x335ec0c5 0x335ec077 0x335ec055 0x335eb90b 0x335ebe01 0x335145f1 0x33501801 0x3350111b 0x351f35a3 0x351f31d3 0x316ce173 0x316ce117 0x316ccf99 0x3163febd 0x3163fd49 0x351f22eb 0x33555301 0x4b81f 0x399bbb20)
Sep 18 15:12:48 iPad ReportCrash[53109] <Notice>: Formulating crash report for process MyApp[53107]
Sep 18 15:12:48 iPad com.apple.launchd[1] (UIKitApplication:com.mycompany.MyApp[0x716c][53107]) <Warning>: (UIKitApplication:com.mycompany.MyApp[0x716c]) Job appears to have crashed: Abort trap: 6
Sep 18 15:12:48 iPad ReportCrash[53109] <Error>: libMobileGestalt copySystemVersionDictionaryValue: Could not lookup ReleaseType from system version dictionary
Sep 18 15:12:48 iPad backboardd[26] <Warning>: Application 'UIKitApplication:com.mycompany.MyApp[0x716c]' exited abnormally with signal 6: Abort trap: 6
Sep 18 15:12:48 iPad ReportCrash[53109] <Notice>: Saved crashreport to /var/mobile/Library/Logs/CrashReporter/MyApp_2013-09-18-151248_iPad.plist using uid: 0 gid: 0, synthetic_euid: 501 egid: 0
This does not occur when I run the app on my device, and it must've worked when Apple review it or else they would not have cleared it for sale.
My guess it that my products array is null and when trying to purchase _products[0] (the only available one) it crashes.
More Info:
I followed Ray Wenderlich's Tutorial when adding In-App Purchases:
[[AppStoreHelper sharedInstance] requestProductsWithCompletionHandler:^(BOOL success, NSArray *products) {
if (success) {
_products = products;
}
[refreshControl endRefreshing];
}];
To sum up: why does it only work in testing mode?
Thanks in advance!
It works now. I guess Apple's servers needed some time to process the purchase...
Related
I've been working on a Linphone custom, it all works fine except that every other call I receive when the app is running on the background ou when the phone is locked, I get this error.
But its like every other call or so...
If anyone could help me =D
Joels-Mac linphone[2257]: linphone(2257,0x700000104000) malloc: *** error for object 0x61800001c6c0: Invalid pointer dequeued from free list
*** set a breakpoint in malloc_error_break to debug
Oct 17 17:36:20 Joels-Mac com.apple.CoreSimulator.SimDevice.3ED2130C-2343-49A3-93CA-24776C42E4D8.launchd_sim[1395] (UIKitApplication:com.routerbox.phoneboxcliente[0x73ea][2257]): Service exited due to Abort trap: 6
Oct 17 17:36:20 Joels-Mac SpringBoard[1412]: UNSUserNotificationServerConnectionListener connection invalidated
I am working with Card.io since long time but now it started to crash accidentally when i tap on camera button to scan card.
Below is the crash logs.
<Error>: *** Terminating app due to uncaught exception 'NSRangeException', reason: '-[NSTaggedPointerString getCharacters:range:]: Range {0, 7} out of bounds; string length 6'
*** First throw call stack:
(0x1845b5900 0x183c23f80 0x1845b5848 0x18459ce88 0x1844a7994 0x18459d634 0x100414aa8 0x1844eda04 0x1004147f4 0x1004153d4 0x10041557c 0x1003e8ea0 0x1892a80c0 0x1892a7cc4 0x189648930 0x189605930 0x189602340 0x189558b70 0x189566030 0x189299c24 0x18456c588 0x18456a32c 0x18456a75c 0x184499680 0x1859a8088 0x189310d90 0x10016de20 0x18403a8b8)
Feb 2 12:15:27 iPhone SpringBoard[54] <Warning>: HW kbd: Failed to set (null) as keyboard focus
Feb 2 12:15:27 iPhone SpringBoard[54] <Warning>: UNNotificationRegistrarConnectionListener connection invalidated
Feb 2 12:15:27 iPhone com.apple.xpc.launchd[1] (UIKitApplication:com.upperlife.instacare[0x4a0a][369]) <Notice>: Service exited due to signal: Abort trap: 6
Feb 2 12:15:27 iPhone SpringBoard[54] <Warning>: Application 'UIKitApplication:com.upperlife.instacare[0x4a0a]' crashed.
Feb 2 12:15:28 iPhone UserEventAgent[23] <Warning>: 215163172432: id=com.upperlife.instacare pid=369, state=0
As you are using old version of Card.io SDK for iOS, so that's the main reason why the crash for iOS 9 is occurring, it has been fixed in version 5.1.0 .
Issue already raised in github:-
https://github.com/card-io/card.io-iOS-SDK/issues/120
Resolved:-
https://github.com/card-io/card.io-iOS-source/commit/b9b3c0a329b75d048a20190f8843da4f247d755a
NSAssert works fine in Xcode 4 (up to 4.6 inclusive) when running debugger. Assertion fires, you breakpoint it, then it outputs the assertion message.
But when running outside the debugger (debug build on device), assertions fire - but with no message.
This makes assertions useless: you can see the line number which asserted, but the detailed message from the programmer has been wiped.
Is this an Xcode problem? A clang/LLVM problem? Is it a setting with the wrong value? Or is there a workaround?
Example code:
NSAssert(FALSE, #"X was invalid: %i", x );
Example output (console):
<Warning>: *** Assertion failure in -[myClass method:], myClass.m:124
<Notice>: Formulating crash report for process MyApp[82]
Expected output (console):
<Warning>: *** Assertion failure in -[myClass method:], myClass.m:124
<Warning>: *** "X was invalid: -435"
<Notice>: Formulating crash report for process MyApp[82]
NB: I'm only guessing how Apple would format the assertion message.
UPDATE: Found the problem. I was wrong with my original description:
The message was not being output to console while running in the debugger
Two observations:
The NSAssert is intended for debugging purposes only. When you build a release version of your app, NSAssert does nothing.
When you use NSAssert in a debug build of an app running on a device (not through the debugger), the message is in the device's console, not Xcode's. If you go to the "Organizer" in Xcode, choose "Devices", select your device and look at the "Console", you'll see your assertion there.
For example, I put in a line of code in a "Assertion Test" app:
NSAssert(FALSE, #"Assertion performed here");
When I look at the device's "Console" through Xcode's Organizer, I see:
Aug 6 09:10:53 Rob-iPod amfid[200] : Aug 6 09:10:53 SecTrustEvaluate [leaf CriticalExtensions IssuerCommonName]
Aug 6 09:10:53 Rob-iPod Assertion Test[199] : *** Assertion failure in -[ViewController viewDidLoad], /Users/rryan/Documents/Development/Xcode/Assertion Test/Assertion Test/ViewController.m:21
Aug 6 09:10:53 Rob-iPod kernel[0] : launchd[199] Builtin profile: container (sandbox)
Aug 6 09:10:53 Rob-iPod kernel[0] : launchd[199] Container: /private/var/mobile/Applications/7A7A62EF-8CEC-4388-932D-5C02DE77B841 (sandbox)
Aug 6 09:10:53 Rob-iPod Assertion Test[199] : *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Assertion performed here'
*** First throw call stack:
(0x315592a3 0x391d797f 0x3155915d 0x31e2eab7 0x843f7 0x33380595 0x333c0d79 0x333bcaed 0x333fe1e9 0x333c183f 0x333b984b 0x33361c39 0x333616cd 0x3336111b 0x350535a3 0x350531d3 0x3152e173 0x3152e117 0x3152cf99 0x3149febd 0x3149fd49 0x333b8485 0x333b5301 0x84149 0x3960eb20)
Aug 6 09:10:54 Rob-iPod ReportCrash[201] : Formulating crash report for process Assertion Test[199]
Aug 6 09:10:54 Rob-iPod com.apple.launchd[1] (UIKitApplication:com.robertmryan.Assertion-Test[0x7be0][199]) : (UIKitApplication:com.robertmryan.Assertion-Test[0x7be0]) Job appears to have crashed: Abort trap: 6
Aug 6 09:10:54 Rob-iPod backboardd[26] : Application 'UIKitApplication:com.robertmryan.Assertion-Test[0x7be0]' exited abnormally with signal 6: Abort trap: 6
Aug 6 09:10:54 Rob-iPod ReportCrash[201] : libMobileGestalt copySystemVersionDictionaryValue: Could not lookup ReleaseType from system version dictionary
Aug 6 09:10:54 Rob-iPod ReportCrash[201] : Saved crashreport to /var/mobile/Library/Logs/CrashReporter/Assertion Test_2013-08-06-091053_Rob-iPod.plist using uid: 0 gid: 0, synthetic_euid: 501 egid: 0
If you look at that fifth line, you'll see the assertion message there.
This is very situation specific ... I hadn't realised, but we had HockeyApp / QuincyKit embedded in the app.
Hockey appears to have a nasty bug where it:
captures NSAssertions
Allows them to crash
Deletes the message
Deletes the logging
... does not upload anything to the Hockey website
So ... the messages were visible in the debugger, but only in the debugger variables - I was a fool, and not paying attention: they weren't appearing in the console.
To be clear: some assertions sometimes appear in Hockey (looking at the Hockey console), but most assertions are silently missing. 100% of App crashes appear, but only about 10% of assertion crashes.
I am trying to debug what appears to be an assertion failure on iOS. The device in question seems to produce no crash logs. Instead, in the console, I see this:
Apr 11 16:22:56 iPhone5 SpringBoard[69] <Warning>: Killing com.yourapp for termination assertion
Apr 11 16:22:56 iPhone5 com.apple.launchd[1] (UIKitApplication:com.appspot.scruffapp[0xa993][19484]) <Notice>: (UIKitApplication:com.yourapp[0xa993]) Exited: Killed: 9
Is there any way to connect this very limited information to an actual source file + line number? Also, why might the device not be creating any crash logs, which are obviously much easier to symbolicate and diagnose?
Thanks,
Eric
Have you tried using:
#try {
//code here
}
#catch (NSError *error) {
NSLog(#"%#", error);
}
I have a app in which i play a splash video and have added some custom fonts.
The app works fine on ipad 3.2 but on 4.2 etc it crashes. The log says that i release something that i dint alloc. I have checked my code a hundred times and i dont do any such thing.
Either ways it works on the simulator and on the device(both 3.2)
any ideas?
EDIT:
<Error>: df(7903,0x3e3d7898) malloc: *** error for object 0x1a11b0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Wed Jan 19 20:35:38 unknown UIKitApplication:com..imagazine[0x9c7c][7903] <Notice>: def(7903,0x3e3d7898) malloc: *** error for object 0x1a11b0: pointer being freed was not allocated
Wed Jan 19 20:35:38 unknown UIKitApplication:com.imagazine[0x9c7c][7903] <Notice>: *** set a breakpoint in malloc_error_break to debug
Wed Jan 19 20:35:39 unknown ReportCrash[7905] <Notice>: Formulating crash report for process df[7903]
Wed Jan 19 20:35:39 unknown com.apple.launchd[1] <Warning>: (UIKitApplication:com.imagazine[0x9c7c]) Job appears to have crashed: Abort trap
Wed Jan 19 20:35:39 unknown SpringBoard[27] <Warning>: Application 'df' exited abnormally with signal 6: Abort trap
Wed Jan 19 20:35:39 unknown ReportCrash[7905] <Error>: Saved crashreport to /var/mobile/Library/Logs/CrashReporter/df_2011-01-19-203538_Sumas-iPad.plist using uid: 0 gid: 0, synthetic_euid: 501 egid: 0
SOLUTION:
First of all use the NSZombies and you will catch such errors.
The Problem: I had a timer setup for every 0.2sec and it was clearing a UIView and allocating it, not every 0.2secs but maybe once every 5secs.
I did a standard check:
if(vewCustom!= nil) {
[vewCustom removeFromSuperView];
[vewCustom release];
vewCustom = nil;
}
But the strange thing was i verified the code hundreds of times and I was not over releasing and either ways it worked on iOS4.2 for iPhone.
I removed the Timer but still it was crashing and then I removed the release and now it works fine.
Strange but it would be good if someone can explain what i was doing wrong.
You could try running the app in debug with zombies enabled. This way you'll get a stack trace on the overreleased object here's a link on how to set it up.
http://iosdevelopertips.com/debugging/tracking-down-exc_bad_access-errors-with-nszombieenabled.html
Assume that the log is true. The easiest way to find it is to enable Zombies and then exercise your application throughly. See here (tip #1):
http://loufranco.com/blog/files/debugging-memory-iphone.html
Another thing to do is a Build and Analyze and look at each thing it flags. In my experience there are very few false positives.
Just noticed this while looking for something else. The reason for the crash is that removeFromSuperview causes the superview to release the view. Thus, the release that follows is redundant (over-release). Won't be an issue with ARC, but could cause some confusion in other situations