topic Potential ARC problem with AGSRequestOperation sharedOperationQueue in ArcGIS Runtime SDK for iOS Questions

Potential ARC problem with AGSRequestOperation sharedOperationQueue

JonDowney — Fri, 22 Mar 2013 13:29:12 GMT

Good morning,

I've been developing a set of custom classes that access a very custom, WMTS-like web service and have come across a rather pesky and intermittent runtime error. During execution in the simulator for iPhone or iPad I randomly receive the an EXC_BAD_ACCESS exception during startup of my application. I ran profiler and believe I have determined that the AGSRequestOperation sharedOperationQueue is getting cleaned up by ARC before it should be. Using a Zombie notifies me that a message was sent to a deallocated object. Further inspection indicates the exception is occurring when I'm trying to add an operation to the sharedOperationQueue.

So, since this is wrapped up in the SDK, I decided to try a little test and downloaded the CustomTiledLayerSample project from your website to check it's behavior. After running it a few times it started to exhibit the same exception-throwing behavior in the exact same place.

Can someone please take a look at this and get back to me ASAP? I've been delaying delivering an application based what appeared to be new functionality in 10.1.1 and not I'm stuck between a rock and a hard place.

Thanks,

Jon

Re: Potential ARC problem with AGSRequestOperation sharedOperationQueue

DanaMaher — Fri, 22 Mar 2013 16:22:45 GMT

Good morning,

Can someone please take a look at this and get back to me ASAP? I've been delaying delivering an application based what appeared to be new functionality in 10.1.1 and not I'm stuck between a rock and a hard place.

Thanks,

Jon

I'm not ESRI, but I saw the same crash when I looked at the custom tiled layer sample and I was able to find a quick workaround to the crash. [AGSRequestOperation sharedOperationQueue] simply returns a subclass of NSOperationQueue. If you create an NSOperationQueue and substitute that for the sharedOperationQueue call, everything runs smoothly. I'm not sure what kind of operation throttling, etc. sharedOperationQueue normally does in response to other stuff going on with the Runtime SDK, but I saw no difference in behavior of the sample app, except that the intermittent crashing went away. If you need to ship this ASAP, probably worth a shot.

I attached an edited version of the sample, with sharedOperationQueue swapped out for an NSOperationQueue. Prior to swapping out the queues, I was seeing crash on layer load about 30% of the time. After swapping, I built, ran, and interacted with the modified sample 12 times and saw no crashing or other issues.

Re: Potential ARC problem with AGSRequestOperation sharedOperationQueue

JonDowney — Fri, 22 Mar 2013 17:00:52 GMT

You may not be ESRI but you just may have saved my day!!! I haven't had time to thoroughly test the solution but at first glance it seems to be working as planned. I've ran it about 30 times and performed plenty of map operations without fail. Thank you!

I did have a comment: shouldn't we update the cancelRequestForKey: function to use the local requestQueue object and not the sharedOperationQueue? Seems like we may be putting operations into one queue and canceling them from another.

Re: Potential ARC problem with AGSRequestOperation sharedOperationQueue

DanaMaher — Fri, 22 Mar 2013 17:03:15 GMT

I did have a comment: shouldn't we update the cancelRequestForKey: function to use the local requestQueue object and not the sharedOperationQueue? Seems like we may be putting operations into one queue and canceling them from another.

Yes, I missed that. All queue interactions should now point to the NSOperationQueue instance. Glad I could help. You might mark the thread as answered if this turns out to be workable after further testing.

Re: Potential ARC problem with AGSRequestOperation sharedOperationQueue

ChristopheFondacci — Sat, 11 Dec 2021 20:35:43 GMT

I think I face the same bug but at another place.

In some use-cases of my app, I need to call :

NSOperation *nsOp = [featureLayer addFeatures:graphics]

When I call this immediately after map creation, I end up (not always, but VERY often) with an EXC_BAD_ACCESS. When I call this after a while, I generally have an operation which is never executed.

I think there are some problems with operation queueing... But since I am not queuing the operation myself (it is internally queued by the "addFeatures" call and it returns the queued NSOperation), I cannot use your workaround.

I tried to add an Objective-C category on AGSRequestOperation so that sharedOperationQueue returns one of my own allocated operation queue. For now it seems to work. But note that it seems not to work with a static variable, don't know why.

@implementation AGSRequestOperation (Operation)

+ (NSOperationQueue *)sharedOperationQueue {
    return [Utils getQueue];
}
@end

And the Utils code :

// Declaration in .h file
@property (nonatomic,strong) NSOperationQueue *operationQueue;

@implementation Utils

- (id)init
{
    self = [super init];
    if (self) {
        _operationQueue = [[NSOperationQueue alloc] init];
        [_operationQueue setMaxConcurrentOperationCount:10];
    }
    return self;
}

+ (NSOperationQueue *)getQueue {
    return _operationQueue;
}
@end

Actually, I don't really know what arcgis does internally to schedule this task. All I know is that there is something not good regarding object allocation / retain thing.

I need some more tests to make sure that it works ALL the time. That would be great to have inputs from an ArcGis guy and to investigate on a fix.

Christophe.