Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Crash during signOutAndRemoveLocalData:YES #424

Closed
CapoChino opened this issue Dec 14, 2014 · 5 comments
Closed

Crash during signOutAndRemoveLocalData:YES #424

CapoChino opened this issue Dec 14, 2014 · 5 comments
Assignees
@jleandroperez

Comments

@CapoChino
Copy link

Hi,

I'm dusting off my Simperium integration in hopes that the bug I was hitting a fews months ago (#250) has been fixed. I'm using the develop branch. (Should I use master instead?)

I called signOutAndRemoveLocalData as follows:

[theSimperium signOutAndRemoveLocalData:YES completion:^{
NSLog(@"Finished logging out.");
isSigningOut = NO;
[self updateInterface];
}];

It's worked fine several times, but just now it crashed. I don't know if it will reproduce. Following is the trace. Let me know if there's anything else you need.

Thank you!

Cheers,
Casey

  • thread Obj-C framework defines categories on NSDate and NSString without prefixes #1: tid = 0x4232a0, 0x000000010bd35017 libobjc.A.dylibobjc_msgSend + 23, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x000000010bd35017 libobjc.A.dylibobjc_msgSend + 23
    frame Obj-C framework defines categories on NSDate and NSString without prefixes #1: 0x00000001097428bd CoreData__77-[NSFetchedResultsController(PrivateMethods) _managedObjectContextDidChange:]_block_invoke + 2045 frame #2: 0x0000000109673f06 CoreDatadeveloperSubmittedBlockToNSManagedObjectContextPerform + 198
    frame Python versions < 2.6 #3: 0x0000000109673de1 CoreData-[NSManagedObjectContext performBlockAndWait:] + 241 frame #4: 0x00000001097420a7 CoreData-[NSFetchedResultsController(PrivateMethods) _managedObjectContextDidChange:] + 119
    frame OSX fails to authenticate #5: 0x000000010c671cec CoreFoundation__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 frame #6: 0x000000010c5718a4 CoreFoundation_CFXNotificationPost + 2484
    frame Table Cell Redraw Issue #7: 0x000000010aeb06b8 Foundation-[NSNotificationCenter postNotificationName:object:userInfo:] + 66 frame #8: 0x0000000109659c96 CoreData-[NSManagedObjectContext(_NSInternalNotificationHandling) _postObjectsDidChangeNotificationWithUserInfo:] + 70
    frame Synchronization status #9: 0x00000001096e2d1e CoreData-[NSManagedObjectContext(_NSInternalChangeProcessing) _createAndPostChangeNotification:withDeletions:withUpdates:withRefreshes:] + 334 frame #10: 0x00000001096553d1 CoreData-[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] + 2897
    frame iOS: Deleting object (tree) gives 409 errors and doesn't sync #11: 0x00000001096588f3 CoreData`-[NSManagedObjectContext save:] + 131
@jleandroperez
Copy link
Contributor

@CapoChino thanks for the report!,

Would it be possible to get the full crashlog? (all of the threads, + if possible, console logs). This seems to be breaking in NSFetchedResultsController (i'm not quite sure what might be causing this, though).

Thank you!

@CapoChino
Copy link
Author

Hi Jorge,

I've been having trouble using NSFetchedResultsController ("FRC") with Simperium. So I decided to take out the FRC and do a more simple pull-to-refresh scheme. This will reload the table data from the database. This approach seems to be more stable. Perhaps this issue was caused by a bug in my FRC implementation as all the entities were deleted by Simperium. It's OK with me to close this bug. I'll let you know if I integrate FRC again and have issues.

Thanks,
Casey

@jleandroperez
Copy link
Contributor

@CapoChino That's not good.. the FRC itself was triggering entity deletions?.

We did experience a DeadLock between FRC and the NSManagedObjectContext architecture we were using (addressed in #376), but so far, we haven't seen a FRC nuking entities.

Were you running code, explicitly, against the MOC? (or it was a simple FRC integration with the MainMOC + a NSFetchRequest instance?).

Thank you!

@jleandroperez jleandroperez self-assigned this Dec 22, 2014
@jleandroperez jleandroperez added this to the v0.7.6 milestone Dec 22, 2014
@CapoChino
Copy link
Author

@jleandroperez I didn't initially realize this was related to FRC because at the point in my app where I sign out, there is no live FRC. Perhaps the problem was I didn't clean up the FRC when the view went away, and so some notification subscriptions were still active..

Anyway, no my FRC was not changing or deleting model objects. It appears in the crash here it was trying to respond to the deletes performed by Simperium during the sign-out.

My FRC implementation wasn't quite straightforward though, which is probably why I had bugs in it. The issue is that my FRC was used to manage 1 section in a table containing 2 or 3 sections. The other sections were not managed by the FRC. The number of those sections and the rows therein were interdependent. They were also dependent on a GPS location callback happening, which is asynchronous. This made my table (with FRC) hard (for me) to get right.

@jleandroperez
Copy link
Contributor

@CapoChino Sorry about the late reply on this one!. I've been unable to repro this crash.

From what you mention, it sounds highly likely that there was a memory leak somehow, and the FRC was getting a notification, when there should have never been a FRC active.

If anything, please, let us know.

Thank you!

@jleandroperez jleandroperez removed the bug label Jan 5, 2015
@jleandroperez jleandroperez removed this from the v0.7.6 milestone Jan 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jleandroperez jleandroperez

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jleandroperez @CapoChino