Getting a strange crash fairly commonly among iPhones sending data between each other over bluetooth. After a lot of effort I still cannot reproduce it in the debugger.
Crash log:
NSInternalInconsistencyException
Invalid parameter not satisfying: request != nil
3 Foundation 0x0000000186d28ed4 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 108
4 CoreBluetooth 0x0000000185aec808 -[CBPeripheralManager respondToRequest:withResult:] + 156
5 CoreBluetooth 0x0000000185aee410 -[CBPeripheralManager handleSetAttributeValues:] + 1104
Don't know what triggers the peripheral manager to call handleSetAttributeValues or where the nil value is coming from here.
There is only one place in the codebase where I call [CBPeripheralManager respondToRequest:withResult:] and I have safeguards around it to ensure that it will never get called if request is nil.
Related
Issue started about 11:20 UK time, and it affects many big applications like spotify, waze, medium and so on.
It looks like it related with event managers and analytics. Some of the apps that crashed 10 min ago, seems working now.
Can it be solved by changing any facebook dev settings?
Anyone able to solve it without waiting Facebook to solve?
For more info:
https://developers.facebook.com/status/issues/1739188102911114/
https://github.com/facebook/facebook-ios-sdk/issues/1430
https://developers.facebook.com/support/bugs/329763701368293/
4 CoreFoundation 0x00007fff23e43bf8 _CF_forwarding_prep_0 + 120
5 FBSDKCoreKit 0x000000010f736f3a +[FBSDKRestrictiveDataFilterManager updateFilters:] + 62
6 FBSDKCoreKit 0x000000010f739a0c +[FBSDKServerConfigurationManager processLoadRequestResponse:error:appID:] + 1912
7 FBSDKCoreKit 0x000000010f739281 __78+[FBSDKServerConfigurationManager loadServerConfigurationWithCompletionBlock:]_block_invoke + 62
8 FBSDKCoreKit 0x000000010f729110 -[FBSDKGraphRequestMetadata invokeCompletionHandlerForConnection:withResults:error:] + 143
9 FBSDKCoreKit 0x000000010f7269fe __82-[FBSDKGraphRequestConnection processResultBody:error:metadata:canNotifyDelegate:]_block_invoke + 142
10 FBSDKCoreKit 0x000000010f72690d -[FBSDKGraphRequestConnection processResultBody:error:metadata:canNotifyDelegate:] + 636
11 FBSDKCoreKit 0x000000010f72654d __64-[FBSDKGraphRequestConnection completeWithResults:networkError:]_block_invoke + 398
From my side, in the response, there is null value. Yes!!! null is a kind of primitive type in JSON specification.
Then after FB using [NSJSONSerialization JSONObjectWithData: options: error:] to serialize this object, it returns NSNull object without error. According to Apple's doc, NSNull is a singleton object. Yes!!!, it is a valid object, not like nil, which you can guard using if (obj) statement
So, when FB try to use if (serializedObj) { ... } to guard this edge cases in many places, it is actually useless. Here serializedObj is a singleton object, the result is YES then it continues to send message, then, unrecoginized selector . This issue haven't been fixed now. Next time, when the server side sends an another object with null, we will see another disaster.
Updated:
FB is trying to fix this issue
I have a symbolicated crash log from Xcode with the following lines:
3 Foundation 0x185a20a1c -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 112 (NSException.m:152)
4 UIKit 0x18a31b044 -[UISlider _setValue:minValue:maxValue:andSendAction:] + 224 (UISlider.m:1396)
5 MyApp 0x10013cea8 -[RecordingPlayer updateRecordingControls:fullUpdate:] + 284 (RecordingPlayer.m:1448)
I can tell from the last line that the app is crashing when I set the maximumValue property of a UISlider. And I can guess from the other two lines that my app is trying to set that property to an invalid value. But is there any way to find out exactly what assertion failed?
If I could find an explanation like "maximumValue must be greater than 0," that would help me understand where in my code this bad value is getting calculated.
Unfortunately, I can't reproduce the problem on my own devices, so I can't debug to inspect the values when the crash occurs.
I'm running corona SDK with a chartboost plugin, and I'm experiencing crashes about 20% of the time at startup, when I try to initialize the plugin (which I can't edit, I don't have the source).
Here's the symbolicated crash report: http://pastebin.com/id1AsjmN
I've been reading up a little on how to make sense of these crash reports, and from what I understand, these two frames in the main thread:
9 CoreFoundation 0x295d9008 +[NSException raise:format:arguments:] + 100
10 Foundation 0x2a2d8bc4 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 88
Are the most critical to understanding my problem. How can I understand what these lines mean? The "object:file:lineNumber:description:" and "raise:format:arguments:" business seems almost cruel, because I feel like those should be filled in with information that would help me -- what class, and line number we're talking about. Am I right? Are these placeholders in the error message? What am I not grokking here? Is there ANY way of knowing where this error came from?
It's not symbolicated crash log. To be more precise, partially symbolicated.
9 CoreFoundation 0x295d9008 +[NSException raise:format:arguments:] + 100
10 Foundation 0x2a2d8bc4 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 88
11 UIKit 0x2d00946e -[UINib initWithNibName:directory:bundle:] + 158
12 UIKit 0x2d00955c +[UINib nibWithNibName:bundle:] + 56
13 splashboardd 0x000bee8c 0xbc000 + 11916
Somewhere in your splashboard code something is called (0x000bee8c 0xbc000 + 11916 - not symbolicated). This calls +[UINib nibWithName:bundle:], which calls -[UINib initWithNibName:directory:bundle:], which causes your crash.
Google for How to symbolicate crash log and when you'll succeed, 0xbc000 + 11916 will be replaced with class name, method name, line number, ... That's the place where the problem is. Also that's the reason why you should keep debug symbols for your app as well. To be able to symbolicate it.
Also sometimes there's useful info in console as well. Additional messages, which can help you with debugging.
We are seeing a strange crash in our map based iOS app that I cannot figure out. Basically as some point the following lines of code repeat over and over, more than 100 times in crash log:
6 VectorKit 0x000000019050c6f8 __86-[VKMapCameraController _animateToPosition:pitch:yaw:duration:timingCurve:completion:]_block_invoke347 + 40
7 VectorKit 0x0000000190485a30 -[VKAnimation _stopAnimation:] + 140
8 VectorKit 0x0000000190488b20 -[VKMapCameraController setYaw:animated:] + 100
9 MapKit 0x000000018540263c -[MKMapView snapToNorth:] + 148
before finally calling:
0 CoreFoundation 0x0000000183251e38 _CFArrayReplaceValues + 152
1 CoreFoundation 0x000000018332876c __CFRepositionTimerInMode + 108
2 CoreFoundation 0x000000018332876c __CFRepositionTimerInMode + 108
3 CoreFoundation 0x0000000183272630 CFRunLoopTimerSetNextFireDate + 580
4 MapKit 0x00000001853e8588 -[MKMapView _didChangeRegionMidstream:] + 196
5 MapKit 0x0000000185404e90 -[MKMapView mapLayer:didChangeRegionAnimated:] + 60
where _CGArrayReplaceValues crashes with a EXC_BAD_ACCESS KERN_PROTECTION_FAILURE at 0x000000016fccbef0 error.
I'd like to point out we never directly call any of the methods in this crash report, in fact VectorKit is completely private Apple framework. The only thing we ever do in the app remotely related is call basic setRegion:animated: methods, usually after a user taps an annotation to center on said annotation. It is also worth pointing out this only happens on iOS 8. Not a single iOS 7 crash has been reported.
Here is a link for full crash report: http://crashes.to/s/f09eb96c753
Any help is appreciated. Thank you.
Try enabling NSZombieEnabled. Once enabled, when an object reaches a retain count of 0, instead of being deallocated it'll morph itself into an NSZombie instance. When a zombie receives a message it will log a warning rather than crashing or behaving in an unpredictable way.
To be quite honest i'm not really sure why this is only crashing on iOS 8 and not iOS 7 but a EXC_BAD_ACCESS signal is the result of passing an invalid pointer to a system call, so you might be dereferencing a null pointer somewhere.
If the above NSZombieEnabled doesn't uncover the issue then try using the Static Analyzer.
I am experiencing an incredibly strange crash inside my override of the encodeWithCoder: method. You can see my implementation at https://github.com/reidmain/FDModel/blob/193b0661f7ab1ce62f80de02bcbfa10a38c58ce9/FDModel/FDModel.m#L340-358
I have received tens of thousands of crash logs similar to the following:
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x5000000c
Crashed Thread: 0
Application Specific Information:
objc_msgSend() selector name: replacementObjectForKeyedArchiver:
Thread 0 Crashed:
0 libobjc.A.dylib 0x38acb626 objc_msgSend + 6
1 Foundation 0x2eca70d7 _encodeObject + 128
2 MyApp 0x00411d8b -[FDModel encodeWithCoder:] + 268
3 Foundation 0x2eca7479 _encodeObject + 1058
4 Foundation 0x2eca8657 -[NSKeyedArchiver _encodeArrayOfObjects:forKey:] + 396
5 Foundation 0x2eca8329 -[NSDictionary(NSDictionary) encodeWithCoder:] + 918
6 Foundation 0x2eca7479 _encodeObject + 1058
7 Foundation 0x2ecf432d +[NSKeyedArchiver archiveRootObject:toFile:] + 202
8 MyApp 0x003dd561 -[MyAppsDataClient _saveObjectsToDisk] + 74
The problem is that inside the company no one has experienced these crashes personally. Even after writing a stress test which calls the method which triggers the encoding every couple seconds and letting it run for an hour nothing happens.
It looks like either FDModel or the object that it is trying to encode is somehow released from memory but how this happens remains a mystery to me. If FDModel was released from memory how would _encodeObject succeed being called? If it was FDModel being released from memory I would expect to see a wide range of crash logs on all sorts of methods being called on FDModel but it not existing in memory. All of the crashes are complaining about replacementObjectForKeyedArchiver:
After talking with an Apple employee on the dev forums it looks like the issue was due to the model being encoded at the same time as it was being modified.
I updated FDModel to use a NSRecursiveLock whenever changes were being made the model or whenever the model was being encoded.