nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Potential ARC problem with AGSRequestOperation sharedOperationQueue

JonDowney

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

Find more posts tagged with

Accepted answers

DanaMaher

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.

All comments

DanaMaher

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.

CustomTiledLayerSample_QueueSwap.zip

JonDowney

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.

DanaMaher

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.

ChristopheFondacci

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.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.