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
Related
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...
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 creating a AVQueuePlayer object by adding AVPlayerItems. All player items points to different audio URL and player should play as soon as it buffers.
As I start the app in simulator, I get very strange issue with memory. The console says
malloc: *** mmap(size=2147483648) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
and stack trace points some where internal in the framework. It juts points at function #0 MP3AudioStream::GeneratePackets(AudioFileStreamContinuation&) ()
I am not able to understand what is the issue.
Even adding breakpoint in malloc_error_break, doesn't giving any info.
Can some one help me in fixing the issue.
Thanks
errno code 12 means out of memory.
Check the size parameter that is passed to malloc - it is invalid. The size value of -1 signed (2147483648 unsigned) explains the out of memory error.
Sorry, but I wasn't sure whether to post Tabris questions here or on GitHub, now that 1.0 is available? This is a dup of one I just raised on GitHub...
I've had Tabris 1.0 for a few days now, running ok on browser and Android, but I cannot get the iOS client to start at all. Here is my error in XCode, which is the same whether it is an emulated device or a real iPad:
2013-04-24 09:45:53.616 RapHello[2636:907] * 17 DAY(S) OF TABRIS TRIAL LEFT
2013-04-24 09:45:53.620 RapHello[2636:907] -[AppDelegate clientDidBecomeReady]: unrecognized selector sent to instance 0x1e51fb70
2013-04-24 09:45:53.621 RapHello[2636:907] Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[AppDelegate clientDidBecomeReady]: unrecognized selector sent to instance 0x1e51fb70'
* First throw call stack:
(0x343ae3e7 0x3c238963 0x343b1f31 0x343b0737 0x34308208 0x342ff349 0x34c16b7f 0x361c3d11 0x36215b7d 0x361bdd1f 0x361bd7ad 0x361bd1ef 0x37eb15f7 0x37eb1227 0x343833e7 0x3438338b 0x3438220f 0x342f523d 0x342f50c9 0x3621446d 0x362112b9 0xb7981 0xb7908)
libc++abi.dylib: terminate called throwing an exception
This happens quite early on. I see the TABRIS logo screen on the device, but then this crash and nothing else happens.
Any ideas what I'm doing wrong - obviously something quite basic.
Thanks, John
To fix that problem you need to add the following method to your AppDelegate.m :
- (void)clientDidBecomeReady {
/*
Called when the Tabris client did become ready and will start a new session.
*/
}
We will fix this in our trial download asap.
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