Crash in [ARTiledImageView downloadAndRedrawTilesWithURLs:] (ARTiledImageView.m:154)

[dblock]

Somehow this can crash:

- (void)downloadAndRedrawTilesWithURLs:(NSDictionary *)urls
{
    __weak typeof (self) wself = self;

    for (NSString *tileCacheKey in urls.keyEnumerator) {
        NSURL *tileURL = [urls objectForKey:tileCacheKey];
        if ([self.downloadOperations objectForKey:tileCacheKey]) {
            continue;
        }

In Artsy's Eigen app: https://rink.hockeyapp.net/manage/apps/37029/app_versions/16/crash_reasons/12678564 (requires logon)

Thread 9 Crashed:
0   libobjc.A.dylib                      0x39e03622 objc_msgSend + 1
1   CoreFoundation                       0x2f4be199 -[__NSDictionaryM objectForKey:] + 142
2   Artsy                                0x001bec5d -[ARTiledImageView downloadAndRedrawTilesWithURLs:] (ARTiledImageView.m:154)
3   Artsy                                0x001bea51 -[ARTiledImageView drawRect:] (ARTiledImageView.m:130)
4   UIKit                                0x31e1bda5 -[UIView drawLayer:inContext:] + 372
5   QuartzCore                           0x31a492c1 -[CALayer drawInContext:] + 100
6   QuartzCore                           0x31b19cb9 tiled_layer_render(_CAImageProvider*, unsigned int, unsigned int, unsigned int, unsigned int, void*) + 1458
7   QuartzCore                           0x31a76f33 CAImageProviderThread(unsigned int*, bool) + 464
8   libdispatch.dylib                    0x3a2e8ad7 _dispatch_root_queue_drain + 220
9   libdispatch.dylib                    0x3a2e8d29 _dispatch_worker_thread2 + 54
10  libsystem_pthread.dylib              0x3a423bd3 _pthread_wqthread + 298
11  libsystem_pthread.dylib              0x3a423a98 start_wqthread + 8

[dblock]

@orta any ideas what this could be?

[orta]

this is weird,

my initial thoughts were that the ARTiledImageView could be nil'd during this, but the crash seems to be entirely related to local scope, so it's very unlikely. Perhaps this is a case of a secondary thread making changes to the urls dictionary? ( again, I think this won't be the case as urls isn't a instance var )

One potential fix, could be to switch to using - (void)enumerateKeysAndObjectsUsingBlock:(void (^)(id key, id obj, BOOL *stop))block but you really should be safe to use the key when you're iterating

[dblock]

The only explanation that I can come up with is that the object is being destroyed on one thread, and still being access on another. We do [self.downloadOperations objectForKey:tileCacheKey], as self.downloadOperations is being cleared because dealloc calls cancelConcurrentDownloads, which calls [self.downloadOperations removeAllObjects];, on different threads.

I added a synchronized block, see cd3cd38.