5

The code below returns the following error when I log/request values from the History Core Data object:

-[CFNumber release]: message sent to deallocated instance 0x17ea2a90

I originally thought there was an issue elsewhere and have spent countless hours attempting to debug this to no luck. After further testing, I have pinpointed the crash to requesting certain values from the History Core Data object. Can anyone see any issues to why the object values are being deallocated?

    [[DocumentHandler sharedDocumentHandler] performWithDocument:^(UIManagedDocument *document) {

    if(!self.document) {
        self.document = document;
    }

    __block NSString *identifier = [[NSUserDefaults standardUserDefaults] objectForKey:kUserDefaultsUserIdentifier];

    [self.document.managedObjectContext performBlock:^{

        // Create history object
        History *history      = [NSEntityDescription insertNewObjectForEntityForName:@"History"
                                                              inManagedObjectContext:self.document.managedObjectContext];
        history.identifier    = identifier;
        history.followers     = [NSNumber numberWithInteger:53];
        history.following     = [NSNumber numberWithInteger:53];
        history.newFollowers  = [NSNumber numberWithInteger:53];
        history.unfollowers   = [NSNumber numberWithInteger:53];
        history.fans          = [NSNumber numberWithInteger:53];
        history.mutualFriends = [NSNumber numberWithInteger:53];
        history.nonFollowers  = [NSNumber numberWithInteger:53];

        [self.document saveToURL:self.document.fileURL forSaveOperation:UIDocumentSaveForOverwriting completionHandler:^(BOOL success) {

            // Fetch previous records
            NSFetchRequest *request = [NSFetchRequest fetchRequestWithEntityName:@"History"];
            request.predicate
            = [NSPredicate predicateWithFormat:@"identifier == %@", identifier];

            NSError *error = nil;

            NSArray *records = [self.document.managedObjectContext executeFetchRequest:request error:&error];

            [records enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
                NSLog(@"%@", [(History *)obj newFollowers]); // Crash takes place here
            }];

        }];

    }];

}];

More logs with an exception breakpoint enabled:

    (lldb) bt
* thread #1: tid = 0x28b70, 0x3b5787fa libobjc.A.dylib`objc_release + 10, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
    frame #0: 0x3b5787fa libobjc.A.dylib`objc_release + 10
    frame #1: 0x3b578022 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
    frame #2: 0x311b4298 CoreFoundation`_CFAutoreleasePoolPop + 16
    frame #3: 0x3127533e CoreFoundation`__NSArrayEnumerate + 614
    frame #4: 0x31216012 CoreFoundation`-[NSArray enumerateObjectsWithOptions:usingBlock:] + 62
    frame #5: 0x000eae26 Twitter Followers`__71-[MainViewController updateCurrentRecordAndTableHeaderForUpdateAction:]_block_invoke_2(.block_descriptor=0x15e58080, success='\x01') + 678 at MainViewController.m:671
    frame #6: 0x3ba65bea libdispatch.dylib`_dispatch_barrier_sync_f_slow_invoke + 66
    frame #7: 0x3ba600ee libdispatch.dylib`_dispatch_client_callout + 22
    frame #8: 0x3ba629a8 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 268
    frame #9: 0x3124b5b8 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
    frame #10: 0x31249e84 CoreFoundation`__CFRunLoopRun + 1308
    frame #11: 0x311b4540 CoreFoundation`CFRunLoopRunSpecific + 524
    frame #12: 0x311b4322 CoreFoundation`CFRunLoopRunInMode + 106
    frame #13: 0x35eeb2ea GraphicsServices`GSEventRunModal + 138
    frame #14: 0x33a6b1e4 UIKit`UIApplicationMain + 1136
morcutt
  • 3,739
  • 8
  • 30
  • 47
  • On which line exactly does the exception occur? Can you provide a stack backtrace? – Martin R Oct 19 '13 at 19:12
  • It occurs during [records enumerateObjectsUsingBlock...]. I just added further logs. These logs are with an exception breakpoint. – morcutt Oct 19 '13 at 19:16
  • I'm getting this error also, but apparently for a different reason (there are no attributes starting with "new"). Is it possible to get any more information about the deallocated object using its address? – Symmetric Nov 04 '13 at 21:09
  • 1
    @Symmetric - I know that's a very old comment, but for the benefit of future readers, I'd suggest you check out the "Record Reference Counts" feature discussed in the latter part of http://stackoverflow.com/questions/14104556/ios-app-with-arc-find-who-is-owner-of-an-object/14105056#14105056. This can be invaluable in tracking down where each strong reference is established (i.e. the reference count is increased +1) and released (i.e. the reference count is decremented -1). – Rob Jan 14 '16 at 07:11
  • I faced with this error when changed type of field from int to NSNumber * but forgot to change property from to assign to strong.The most weird was that on IPhone 6/6s everything was fine but on IPhone 5/5s crash. – Bohdan Savych Aug 02 '16 at 08:33

1 Answers1

22

According to the Transitioning to ARC Release Notes:

To allow interoperation with manual retain-release code, ARC imposes a constraint on method naming:

  • You cannot give an accessor a name that begins with new. This in turn means that you can’t, for example, declare a property whose name begins with new unless you specify a different getter:

        // Won't work:
        @property NSString *newTitle;
    
        // Works:
        @property (getter=theNewTitle) NSString *newTitle;
    

Bottom line, methods that start with new are assumed to return an object that ARC is responsible for managing and releasing (but this isn't the case here). I'd suggest just changing your property so that it doesn't start with new to avoid any confusion.

Rob
  • 415,655
  • 72
  • 787
  • 1,044
  • Do you know if there is a way to have xcode throw a warning if you have fields like this? I spend hours tracing down a malloc double free error and it was because I started the variable with new. – Jeff Moore Jul 03 '14 at 04:24
  • @JeffMoore Not that I know of. Might be a good feature request for http://bugreport.apple.com. – Rob Jul 03 '14 at 06:49
  • @Rob Does the same go for variables? I have had the same crash for ages and I couldn't figure out why. This might be it. – IluTov Nov 18 '14 at 19:20
  • This is just a method naming issue (and because properties synthesize accessor methods, property name issue, too). I am unaware of any equivalent variable naming considerations. – Rob Nov 18 '14 at 20:29
  • I got crash of CFNumber Release in swift code with property starts with new, when I changed it to theNew, it worked. thanks. – Dhaval Panchal Aug 06 '15 at 06:55
  • great it does work. but in my case i was using @property (nonatomic, assign) NSString *skuimage; – ChenSmile Nov 23 '15 at 12:56
  • @Imran - That's a very different issue. But you're using `assign` which means "don't establish a strong reference (i.e. let it be deallocated if there are no other strong references), but also keep dangling reference to any deallocated objects." It's almost an invitation for this sort of problem. Use `strong` or `copy` if you want to keep a reference to it, or use `weak` if you don't need `strong` reference, but instead want to `nil` the reference when the object is deallocated. With ARC, `assign` is not generally a good idea with objects (but fine with fundamental types like `NSInteger`). – Rob Jan 14 '16 at 07:14