NSArray countByEnumeratingWithState sent to deallocated instance

Question

I'm getting this error:

With no stack trace.

-[__NSArrayI countByEnumeratingWithState:objects:count:]: message sent to deallocated instance

What would call this method?

Is it possible to pin down what's calling this? I have zombies on but don't see the caller.

Here's thread1:

The only other clickable line is this from AFNetworking ([runloop run]). I just upgraded my AFNetworking pod.

+ (void)networkRequestThreadEntryPoint:(id)__unused object {
    @autoreleasepool {
        [[NSThread currentThread] setName:@"AFNetworking"];

        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
        [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
        [runLoop run];
    }
}

EDIT: The above breakpoint on @autoreleasepool was not even hit. I did find this in my code on the same crash in another thread (didn't see this last time):, on the archiveSuccessful = line

- (void)archiveContent:(BOOL)changeNotification userInfo:(NSDictionary *)userInfo {
    BOOL archiveSuccessful;
    @synchronized(self) {
        archiveSuccessful = [NSKeyedArchiver archiveRootObject:self.contentDictionary toFile:self.filePath];
    }
    if (archiveSuccessful) {
        if(changeNotification && self.contentChangedNotificationName) {
            [[NSNotificationCenter defaultCenter] postNotificationName:self.contentChangedNotificationName object:nil userInfo:userInfo];
        }
    } else {
        NSAssert(NO, @"Saving archive to %@ was not successful", self.filePath);
    }
}

This is called by

- (void)addObjects:(NSArray *)objects changeNotification:(BOOL)changeNotification {
    [objects enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
        if([obj conformsToProtocol:NSProtocolFromString(@"DRLocalObject")]) {
            [self addObject:obj changeNotification:NO];
        }
    }];

debugger printouts from the [self addObject... line

(lldb) po obj
0x00007fde0ff56770

(lldb) po 0x00007fde0ff56770
140591727208304

EDIT:

threadMain: called from Google analytics. A project find & quick open shows no selector named threadMain:

Answer 1

(This is a very hard kind of bug to debug via StackOverflow, so I'm just giving pointers here.)

You almost certainly are modifying some data structure on multiple threads. Given the specifics, I suspect there's an array that is an ivar of some object that you drop on one thread while you're enumerating over it on some other thread. You drop it either by deallocating the owning object, or by replacing the array.

The fact that you're calling @synchronized(self) strongly suggests that you're doing dangerous threading in this program. In modern ObjC, @synchronized is almost never the right tool. If you're using NSThread directly, that is probably also a source of your troubles (AFNetworking is old enough to get a pass on this, but you should not copy their approach). The right tool for handling concurrency is either GCD (dispatch_*) or NSOperation.

Have you verified that every mutation of self.contentDictionary and self.filePath is also synchronized. I would particularly be suspicious of self.contentDictionary because it is the kind of thing that might have arrays in it.

Kudos on correctly using accessors here BTW, though if they're not atomic, it is possible to get inconsistent state on them if you read and write them on different threads. Making them atomic does not make them fully thread safe; you still really need to be using something like GCD or NSOperation to serialize access.

The fact that you call @synchronized and then post a notification in the same method is also somewhat suspicious. Notifications synchronously process on the same thread that they are posted on, so your notification observers need to be aware of what thread they may be called on.

Note that crashing in the AFNetworking runloop processing method is meaningless. That's giving you no real hints.

I would look to your threading. Look particularly for unprotected access to arrays (and particularly array properties). And make sure that you serialize all your accesses with GCD or NSOperation, not @synchronize.