iOS Amazon S3 SDK: message sent to deallocated instance - ios

I'm getting the following error:
*** -[S3PutObjectOperation_Internal respondsToSelector:]: message sent to deallocated instance 0x43c18fd0
I don't understand the stack trace from Zombies inspector very well, I'm not sure this is telling me anything I can fix:
# Address Category Event Type RefCt Timestamp Size Responsible Library Responsible Caller
0 0xc071f60 S3PutObjectOperation_Internal Malloc 1 00:14.903.021 48 MyApp -[S3TransferManager upload:]
1 0xc071f60 S3PutObjectOperation_Internal Retain 2 00:14.903.032 0 Foundation ____addOperations_block_invoke_0
2 0xc071f60 S3PutObjectOperation_Internal Release 1 00:14.903.036 0 MyApp -[S3TransferManager upload:]
3 0xc071f60 S3PutObjectOperation_Internal Retain 2 00:14.904.154 0 libsystem_sim_blocks.dylib _Block_object_assign
4 0xc071f60 S3PutObjectOperation_Internal Retain 3 00:14.904.163 0 libsystem_sim_blocks.dylib _Block_object_assign
5 0xc071f60 S3PutObjectOperation_Internal Release 2 00:14.904.164 0 Foundation __destroy_helper_block_474
6 0xc071f60 S3PutObjectOperation_Internal Retain 3 00:14.906.549 0 MyApp -[S3PutObjectOperation_Internal start]
7 0xc071f60 S3PutObjectOperation_Internal Release 2 00:14.906.554 0 MyApp -[S3PutObjectOperation_Internal start]
8 0xc071f60 S3PutObjectOperation_Internal Release 1 00:14.907.624 0 MyApp __destroy_helper_block_
9 0xc071f60 S3PutObjectOperation_Internal Retain 2 00:15.243.299 0 MyApp -[S3PutObjectOperation_Internal finish]
10 0xc071f60 S3PutObjectOperation_Internal Retain 3 00:15.243.302 0 MyApp -[S3PutObjectOperation_Internal finish]
11 0xc071f60 S3PutObjectOperation_Internal Release 2 00:15.243.307 0 MyApp -[S3PutObjectOperation_Internal finish]
12 0xc071f60 S3PutObjectOperation_Internal Release 1 00:15.243.330 0 MyApp -[S3PutObjectOperation_Internal finish]
13 0xc071f60 S3PutObjectOperation_Internal Release 0 00:15.244.420 0 Foundation __release_object_op
14 0xc071f60 S3PutObjectOperation_Internal Zombie -1 00:15.386.107 0 MyApp -[S3Response connection:didSendBodyData:totalBytesWritten:totalBytesExpectedToWrite:]
This error happens when the application is uploading photos. The Photo object uses and implements the following methods:
-(void)request:(AmazonServiceRequest *)request didSendData:(NSInteger)bytesWritten totalBytesWritten:(NSInteger)totalBytesWritten totalBytesExpectedToWrite:(NSInteger)totalBytesExpectedToWrite
{
NSLog(#"didSendData called: %d - %d / %d", bytesWritten, totalBytesWritten, totalBytesExpectedToWrite);
self.transferProgress += bytesWritten;
float p = (float) self.transferProgress / self.uploadSize;
self.uploadProgress = [NSNumber numberWithFloat:p];
}
-(void)request:(AmazonServiceRequest *)request didCompleteWithResponse:(AmazonServiceResponse *)response
{
NSLog(#"didCompleteWithResponse called.");
}
-(void)request:(AmazonServiceRequest *)request didFailWithError:(NSError *)error
{
NSLog(#"didFailWithError called: %#", error);
}
As far as I know this is the only point in the app in which the S3 request is talking to any other objects/instances. Any idea what is causing this error?

I think this is a bug in the AWS SDK. I'm not sure where exactly the bug is but it's triggered by request retries if the response was a service exception (and possibly only in conjunction with S3TransferManager).
I didn't want to disable all retries, so I fixed this by forcing no retries for service exceptions. You can do this by using a subclass of AmazonS3Client where you override one method like this:
- (BOOL)shouldRetry:(AmazonServiceResponse *)response exception:(NSException *)exception
{
// There is some kind of bug that is triggered on request retries when S3 requests
// return an explicit service exception (e.g., auth token expired). In these cases
// we force no retry to avoid the bug.
NSException *exceptionHolder = response.exception;
if(exceptionHolder == nil)
{
exceptionHolder = exception;
}
if([exceptionHolder isKindOfClass:[AmazonServiceException class]])
{
return NO;
}
return [super shouldRetry:response exception:exception];
}

Related

iOS crash Assertion Failure on CBPeripheralManager AddService:

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

iOS Core Data dispatch_async background queuing crash

I'm getting a non-reproduceable crash and I'm not sure why. I'm caching images on a background queue. The image names are properties on a Core Data NSManagedObject subclass, CCCard. At the same time, I have a collection view that is also accessing these CCCards.
Here is the relevant code and notes to follow.
//CCDeckViewController.m --------------------------------------
- (void)viewDidLoad {
// This will fetch the CCCard objects from Core Data.
self.cards = [[CCDataManager shared] cards];
[self cacheImages];
}
- (void)cacheCardImages {
// Because these are NSManagedObjects, I access them in the background
// via their object ID. So pull the IDs out here.
NSArray *cardIds = [self.cards valueForKey:#"objectID"];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
for (NSManagedObjectID *cardId in cardIds) {
// Fetch the actual CCCard object.
CCCard *card = (CCCard *)[[CCDataManager shared] objectWithId:cardId];
// Cache the card's image if it's not already there.
NSString *key = [card thumbnailCacheKey];
if ([self.cardImageCache objectForKey:key]) {
continue;
}
CCDiscardableImage *discardable = [CCHelper decompressedImageForPath:key size:[card thumbnailSize] tintable:[card tintable]];
[self.cardImageCache setObject:discardable forKey:key];
}
});
}
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath {
CCCard *card = self.cards[indexPath.item];
// This line calls the code that crashes.
UIColor *color = [card color];
// More code that returns the cell.
}
// CCCard.m --------------------------------------
- (UIColor *)color {
// Crash happens on this line.
if (self.colorId.integerValue == 0) {
// some code
}
}
Here are parts of the stack trace from the Crashlytics report I think are most relevant:
Thread #0: Crashed: com.apple.main-thread
EXC_BREAKPOINT 0x000000000000defe
0 CoreData 0x24c1b070 _sharedIMPL_pvfk_core + 247
1 CoreData 0x24c1b071 _sharedIMPL_pvfk_core + 248
2 myapp 0x4286f -[CCCard color] (CCCard.m:37)
3 myapp 0x40bbb -[CCDeckViewController collectionView:cellForItemAtIndexPath:] (CCDeckViewController.m:127)
Thread #4: com.apple.root.utility-qos
0 libsystem_pthread.dylib 0x2321920c RWLOCK_GETSEQ_ADDR
1 libsystem_pthread.dylib 0x23219295 pthread_rwlock_unlock + 60
2 libobjc.A.dylib 0x22cb8e01 rwlock_tt<false>::unlockRead() + 8
3 libobjc.A.dylib 0x22cb5af5 lookUpImpOrForward + 488
4 libobjc.A.dylib 0x22cb5903 _class_lookupMethodAndLoadCache3 + 34
5 libobjc.A.dylib 0x22cbbd7b _objc_msgSend_uncached + 26
6 CoreData 0x24c1d3ab _PFObjectIDFastEquals64 + 38
7 CoreFoundation 0x233eeed4 CFBasicHashFindBucket + 1820
8 CoreFoundation 0x233ee775 CFDictionaryGetValue + 116
9 CoreData 0x24c17037 _PFCMT_GetValue + 122
10 CoreData 0x24c16ec7 -[NSManagedObjectContext(_NSInternalAdditions) _retainedObjectWithID:optionalHandler:withInlineStorage:] + 58
11 CoreData 0x24c1b45d _PF_FulfillDeferredFault + 940
12 CoreData 0x24c1afcf _sharedIMPL_pvfk_core + 86
13 myapp 0x42991 -[CCCard imagePath] (CCCard.m:53)
14 myapp 0x41d5b __39-[CCDeckViewController cacheCardImages]_block_invoke (CCDeckViewController.m:295)
It's frustrating because it never happens during development, so can't test any theories. I'm trying to understand the code and crash report to figure out the problem now. My guess is that it has something to do with faulting because it accesses the CCCard object's instance method, but then crashes when trying to read the property from it. But why?
You are violating thread confinement.
Per the Core Data documentation, a NSManagedObjectContext and any NSManagedObject associated with it must only be accessed on the queue that it is assigned to.
Your dispatch_async violates that rule and needs to be corrected. There is no longer a design where you can use Core Data in a dispatch_async like that.
If you want the processing to be asynchronous then you should spawn a private NSManagedObjectContext that is a child of your main NSManagedObjectContext and then execute a -performBlock: against it. That will give you background processing that is configured properly.
Also, I highly recommend turning on -com.apple.CoreData.ConcurrencyDebug 1 as that will catch issues like this during development.

SpeechKit SDK (Dragon Mobile) - Crash on Initialization

We have a repeating crash when initilizing Speechkit.
It only happens sometimes on both iOS7 & iOS8 and we could not identify a specific scenario.
We were using ver. 1.0.3 and upgraded to 1.4.12. This issue happens in both versions.
The trace looks like:
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x00000000
Thread : Crashed: com.apple.main-thread
0 CoreFoundation 0x25521ca4 CFArrayGetCount + 23
1 24me 0x00548de1 -[TAGPValue(Hash) hash]
2 24me 0x00548de1 -[TAGPValue(Hash) hash]
3 24me 0x00548bf3 -[TAGPValue(Hash) hash]
4 24me 0x00548513 -[TAGPValue(Hash) hash]
5 24me 0x0054b6a9 -[TAGPValue(Hash) hash]
6 24me 0x0038ab17 -[ViewController setupTextToSpeechInterface] (ViewController.m:1370)
7 24me 0x0037a481 -[ViewController viewDidLoad] (ViewController.m:196)
//this is the method we use to initialise
-(void)setupTextToSpeechInterface{
if (![SpeechKit sessionID]) {
[SpeechKit setupWithID:#"XXXXXXXXXXXX"
host:#"ti.nmdp.nuancemobility.net"
port:443
useSSL:NO
delegate:nil];
}
}

I cannot catch the "No space left on device" exception when using NSFileHandle writedata function

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.

NSArray exception when adding track to starred playlist

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];
}];
}
}];
}

Resources