I am facing crash issue on iOS CoreBluetooth's
[CBPeripheralManager AddService:].
Seems it occurred due to assertion failure in addService method. Tried so many ways, still can't figure out the issue.
As per my understanding this is not null pointer exception as I already tested passing nil value as AddService parameter which yield different issue.
I have implemented all the delegates of CBPeripheralManager including CBCentral delegates.
In general it works fine. Normally I can't reproduce this issue with intention. But it occurs suddenly.
Please help
.
Crash log:
0 CoreFoundation 0x18b3cafe0 __exceptionPreprocess + 124
1 libobjc.A.dylib 0x189e2c538 objc_exception_throw + 56
2 CoreFoundation 0x18b3caeb4 +[NSException raise:format:arguments:] + 104
3 Foundation 0x18be62720 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 112
4 CoreBluetooth 0x1922ab420 -[CBPeripheralManager addService:] + 820
5 MyApp 0x10110e1f4 -[MyPeripheralManager addServiceIntoPeripheralManager] (MyPeripheralManager.m:202)
Code Snipet:
-(void)addService{
if (!isServiceAdded) {
CLLog("Add Service timer started");
[backgroundTaskManager manageBackgroundRunningTask];
/*
AddService will be called after 5 seconds
when application launching finished or iOS BT on
*/
[self performSelector:#selector(addServiceIntoPeripheralManager) withObject:self afterDelay:SERVICE_ADDING_DELAY]; // 5 secs
} else {
CLDbg("Service already added");
}
}
- (void)addServiceIntoPeripheralManager{
CLLog("Add Service timer expired");
CLDbg("Service Adding: %#", [UUIDString]);
[cbPeripheralManager addService:Service];
}
Thanks in advance.
You are not implementing the callback updates of your BluetoothManager
see this answer
and This answer
I hope this will help you
Related
I am using Alamofire and after several hours of my app running on the simulator I got a crash with this error.
*** Terminating app due to uncaught exception 'NSGenericException', reason: 'Start date cannot be later in time than end date!'
I got this stack trace in console:
*** First throw call stack:
(
0 CoreFoundation 0x0000000111186d4b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x0000000110be821e objc_exception_throw + 48
2 Foundation 0x00000001107f0e3c -[_NSConcreteDateInterval dealloc] + 0
3 CFNetwork 0x00000001131a18e8 -[__NSCFURLSessionTaskMetrics _initWithTask:] + 868
4 CFNetwork 0x00000001131a1497 -[NSURLSessionTaskMetrics _initWithTask:] + 100
5 CFNetwork 0x0000000112f77bc7 -[__NSCFURLLocalSessionConnection _tick_finishing] + 351
6 libdispatch.dylib 0x00000001128e3978 _dispatch_call_block_and_release + 12
7 libdispatch.dylib 0x000000011290d0cd _dispatch_client_callout + 8
8 libdispatch.dylib 0x00000001128eae17 _dispatch_queue_serial_drain + 236
9 libdispatch.dylib 0x00000001128ebb4b _dispatch_queue_invoke + 1073
10 libdispatch.dylib 0x00000001128ee385 _dispatch_root_queue_drain + 720
11 libdispatch.dylib 0x00000001128ee059 _dispatch_worker_thread3 + 123
12 libsystem_pthread.dylib 0x0000000112cbc736 _pthread_wqthread + 1299
13 libsystem_pthread.dylib 0x0000000112cbc211 start_wqthread + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Did someone get the similar crash?
Thanks
I had the same crash and did some research today and found this:
http://www.openradar.me/28301343
It looks Apple fixed the issue in iOS 10.2. just thought it may help you!
Yes I just got the same exact crash. It happened in a background thread and it seems to have to do with making a URL session network request. I wonder if it's some sort of multithreading bug having to do with the fact that I'm making two network requests at the same time. I'm using Alamofire as well but not sure if the bug lies in Alamofire or in Apple's code. I've been unable to reproduce it as of now. Maybe you can figure out how to reproduce it and then file an issue in Apple's bug radar or in the Alamofire GitHub repo.
This is a bug in Apple's NSURLSessionTaskMetrics code and happens during a network request when the user's clock gets moved far enough backwards that the request start timestamp is after the request end timestamp. This is reproducible using a network debugging proxy and manually adjusting the clock, and only occurs from iOS 10.0 up to but not including iOS 10.2
If you're using Alamofire, and you don't need NSURLSessionTaskMetrics, you can work around this by using a custom SessionDelegate for your SessionManager and overriding the responds(to aSelector..) function e.g:
class MySessionDelegate: Alamofire.SessionDelegate {
override public func responds(to aSelector: Selector) -> Bool {
let result: Bool = super.responds(to: aSelector)
if #available(iOS 10.2, *) {
// NSURLSessionTaskMetrics date crash is fixed
return result
} else if #available(iOS 10.0, *) {
// NSURLSessionTaskMetrics date crash is not fixed, turn off metric collection
if aSelector == #selector(self.urlSession(_:task:didFinishCollecting:)) {
return false
} else {
return result
}
} else {
// NSURLSessionTaskMetrics doesn't exist
return result
}
}
}
If you're using the default SessionManager (e.g. calling Alamofire.request(...)) you can create your own SessionManager instead in order to use your custom SessionDelegate:
let sessionManager: Alamofire.SessionManager = {
let configuration: URLSessionConfiguration = URLSessionConfiguration.default
configuration.httpAdditionalHeaders = SessionManager.defaultHTTPHeaders
return Alamofire.SessionManager(configuration: configuration, delegate: MySessionDelegate(), serverTrustPolicyManager: nil)
}()
And now instead of calling Alamofire.request(...) you'd call sessionManager.request(...)
I have been struggling with this problem in an os x application for the last few months and have found a workaround.
Background:
Like the OP am using Alamofire to request JSON data via a Timer to send requests several times per second. The data comes in as expected however I get random crashes at irregular intervals with the same message as the OP i.e. Start date cannot be later in time than end date! etc etc.
Solution:
Rather than send Alamofire requests at a regular interval I added some logic which checks for a return of the previous request before sending the next one. This completely eliminated the random crashes.
Hope it helps :)
#thierryb
I was following Google's documentation for using NearbyMessages API. I'm using Swift3. I have the following code to set up the app to publish to nearby.
let messageManager = GNSMessageManager(apiKey: "someky")
var publication: GNSPublication?
let message = GNSMessage(content:"name".data(using: .utf8))
if let messageManager = messageManager, let message = message {
publication = messageManager.publication(with:message)
}
I ran the app on the simulator. Then the app crashes in the 5th line (The line in the if-let block). Here's part of the stack trace:
(
0 CoreFoundation 0x000000011302334b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x000000011271e21e objc_exception_throw + 48
2 CoreFoundation 0x000000011308c265 +[NSException raise:format:] + 197
3 Foundation 0x0000000112229fdc -[NSConcreteMutableAttributedString initWithString:] + 129
4 ProjectLibs 0x000000011879b55a gns_localizedAllowAppToConnectAttributedString + 415
5 ProjectLibs 0x000000011879b8b9 gns_localizedAllowAppToConnectString + 75
6 ProjectLibs 0x000000011879ae9f gcp_verifyDealloc + 24324
)
Since the messageManager and the message are both protected by the if-let block, I cannot find where is the nil exception coming from. Does anyone know why would there be a nil value in this block of code?
Thank you very much!
Does it work on a device? There is a bug in Nearby Messages 1.1.0 that causes a nil pointer exception on the simulator when you use BLE as a discovery medium.
Apologies! We'll get the bug fixed in the next release.
I used NSFileHandle to writedata to a file.
NSFilehandle *handle = [NSFileHandle fileHandleForWritingAtPath:#"path/of/file"];
#try {
[handle writedata:data];
} #catch (NSException *e) {
// when exception occur, never got here
NSLog(#"%#", e);
}
As my device disk space is full, calling writedata will fail. But I can't catch the exception.
My program log info:
2014-05-23 16:17:24.435 mytest[12919:3203] An uncaught exception was raised
2014-05-23 16:17:24.435 mytest[12919:3203] *** -[NSConcreteFileHandle writeData:]:
No space left on device
2014-05-23 16:17:24.436 mytest[12919:3203] (
0 CoreFoundation 0x00007fff8fae725c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff8cbb3e75 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8fae710c +[NSException raise:format:] + 204
3 Foundation 0x00007fff93640f31 __34-[NSConcreteFileHandle writeData:]_block_invoke + 84
4 Foundation 0x00007fff93840020 __49-[_NSDispatchData enumerateByteRangesUsingBlock:]_block_invoke + 32
5 libdispatch.dylib 0x00007fff8bfc2fad _dispatch_client_callout3 + 9
6 libdispatch.dylib 0x00007fff8bfc2f28 _dispatch_data_apply + 113
7 libdispatch.dylib 0x00007fff8bfc9502 dispatch_data_apply + 31
8 Foundation 0x00007fff9383fff9 -[_NSDispatchData enumerateByteRangesUsingBlock:] + 83
9 Foundation 0x00007fff93640ed2 -[NSConcreteFileHandle writeData:] + 150
10 ZiSyncMac 0x000000010000b1eb -[TransferFile writePart:data:] + 475
I found out writedata calls a dispatch to do real write data to the file system. So I think writedata will throw a exception in GCD.
How can I handle the GCD exception in my code?
From a website that's been hijacked since (not providing the link for that reason, but the explanation is still useful):
seekToEndOfFile() and writeData() are not marked as throws (they don’t
throw an NSError object which can be caught in with a do-try-catch
block), which means in the current state of Swift, the NSExceptions
raised by them cannot be “caught”.
If you’re working on a Swift project, you could create an Objective-C
class which implements your NSFileHandle methods that catches the
NSExceptions (like in this question), but otherwise you’re out of
luck.
What #eric said is right.
But, what you can do is check before that you write for how much space is left in the disk and only after it write to the disk.
I'm getting a rare and intermittent crash which looks like appendBytes being called with -1 as it's length.
now, I've hard coded the "length" argument every time I've used this method so I can't see how this could happen and worse still I can't see how I could test for and avoid this crash.
here's the top of the stack and the exception (note the ~4.2b length):
*** Terminating app due to uncaught exception 'NSMallocException', reason: '*** -[NSConcreteMutableData appendBytes:length:]: unable to allocate memory for length (4294967295)'
*** Call stack at first throw:
(
0 CoreFoundation 0x91ec5a67 __raiseError + 231
1 libobjc.A.dylib 0x9950a149 objc_exception_throw + 155
2 CoreFoundation 0x91e2d289 +[NSException raise:format:arguments:] + 137
3 CoreFoundation 0x91e2d1f9 +[NSException raise:format:] + 57
4 Foundation 0x92d2489e _NSMutableDataGrowBytes + 1136
5 Foundation 0x92d24391 -[NSConcreteMutableData appendBytes:length:] + 354
here's a simplified version of the code that's supposedly crashing:
if (self.isConnectedToService) {
NSMutableData *myData = [NSMutableData data];
float newValue = PanValue;
const char theTwo[] = {(char)Chan_L, (char)PanParam};
[myData appendBytes:&theTwo length:2];
[myData appendBytes:&newValue length:4];
}
So length is always 2 or 4.
I've tested different situations in which the buffers contain more or less than 2 and 4 and I've never managed to cause this crash intentionally.
I've got the same code running on both MacOS10.7.4 and iOS6.0(on iPad3) and see this issue occasionally on both platforms.
so how is appendBytes getting that bogus value?
Sometimes, I'm getting a fatal exception when trying to "star" a track in cocoalibspotify. I'm logging in with a user with a heavy dataset (hundreds of playlists, but < 15 starred tracks).
This is how I "star" the SPTrack:
[[[[SPSession sharedSession] starredPlaylist] items] addObject:myTrack];
... and the stack trace:
*** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSArray objectsAtIndexes:]: index 12 beyond bounds [0 .. 11]'
*** Call stack at first throw:
(
0 CoreFoundation 0x01e125a9 __exceptionPreprocess + 185
1 libobjc.A.dylib 0x021a1313 objc_exception_throw + 44
2 CoreFoundation 0x01da0f99 -[NSArray objectsAtIndexes:] + 633
3 Foundation 0x016a250b -[NSKeyValueArray objectsAtIndexes:] + 110
4 Foundation 0x016aaca6 NSKeyValueDidChangeByArrayMutation + 103
5 Foundation 0x01610c30 NSKeyValueDidChange + 266
6 Foundation 0x016aba95 -[NSObject(NSKeyValueObserverNotification) didChange:valuesAtIndexes:forKey:] + 123
7 Foundation 0x016a4d0e -[NSKeyValueNotifyingMutableArray addObject:] + 239
8 MyApp 0x000922cd -[PlaylistManager starTrack:] + 285
...
This only seems to happen within a minute or two after logging in (i.e. user data is loaded), so I'm guessing it might be an issue where the data isn't fully loaded or something?
I've tried to find out if there's any properties to observe in order to find out when everything's fully loaded. But as the array might be empty (and the user might not have starred any tracks before), it seems like there's no good way of validating that everything's loaded...? The loaded property of SPPlaylist seems to refer to the playlist metadata, and not its tracks (?).
Any ideas?
You are getting the So it looks like you're not supposed to manipulate that array directly. Instead call [myTrack setStarred:YES];
Basically, I just went through the entire Spotify API for you to find that answer.
A full code sample for this:
-(void)starTrack:(NSString *)uri {
NSURL *trackURL = [NSURL URLWithString:uri];
[[SPSession sharedSession] trackForURL:trackURL callback:^(SPTrack *track) {
if (track != nil) {
[SPAsyncLoading waitUntilLoaded:track timeout:kSPAsyncLoadingDefaultTimeout then:^(NSArray *tracks, NSArray *notLoadedTracks) {
[track setStarred:YES];
}];
}
}];
}