When I use the latest code, I get difficult to decipher crashes:
I'm using saveInBackgroundWithBlock, which is being done when I receive a response from AFJSONRequestOperation. I've turning my FRC delegate methods on and off, but still get the same crashes, so it doesn't seem to be that.
I've tried calling and not calling MR_saveNestedContexts in the completion block for saveInBackgroundWithBlock but that does not seem to make a difference.
I do also have some Core Data observers, but I've tried disabling those as well, but to no avail.
Any suggestions on where to turn next in debugging this, based on the screenshots and general approaches I'm using?
My code runs fine with a much earlier version of MR from the Sept time frame, but I don't get permanent IDs with that one and inconsistent saving to the store, so I think I really need to be back on the latest, but just can't get past this bug.
Hi @robreuss — you should start with this post, and see if you can get more detail about what the message is that's being sent: http://sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html
Is your project using MRR or ARC?
Thanks - it could be an issue of sending a message to a deallocation object. I'll confirm I'm properly holding on to the FRC - that seems like a good place to start.
@tonyarnold thanks again for trying to help.
i confirmed that i'm holding on to the reference to the FRC okay. i'll continue to look for possibly deallocated objects that are being sent messages.
i tried to follow the instructions at the link about to interrogate the selector, but i'm not getting the kind of message in the debugging console the approach depends upon, and also the approach is somewhat old (2008) and assumes GDB versus LLDB. if you're handy at doing that kind of thing and can let me know what debugger command I should issue to come up with the selector, that would be awesome.
i did notice that when, in the debugger, i drop down the call stack for the thread that crash occurred on, I see the following: http://snag.gy/8OGAb.jpg
iOS 5 or 6?
I didn't mention above, but I am using MRs method for creating an FRC.
You're welcome, @robreuss — sorry the link wasn't a bit more of a help. I'd completely forgotten that we've all switched to LLDB and that article is for GDB 😢
You're not overreleasing any of your managed objects are you?
By overreleasing my managed objects, do you mean setting them to nil when I shouldn't be?
FYI, I went back a few versions and I don't see this error with 2.0.3 but do see it with 2.0.4. Unfortunately, 2.0.3 does not save to the persistent store (for me).
@tonyarnold I'm now using 2.0.3 and I implemented your fix from #242 and it's now saving to the persistent store. which is awesome, and probably covers me for now...need to do more testing...but i would really like to be on the latest! :(
@tonyarnold BTW, in the version that I've put together (2.0.3 plus the fix) I need to do a MR_saveNestedContexts in the completion block of saveInBackgroundWithBlock. I'm not sure if that's the way it's supposed to work - I guess my sense was that the main block would save (as implied by the readme file). It's not a big deal though.
It should . There was a bug where it didn't a while back.
any harm in just calling MR_saveNestedContexts or should I try to track down the fix and apply it locally?
Do it in the save block, not the completion block, and you should be fine.
Any chance you can post the code involved here? Could you post the entire stacktrace?
Calling it in the save block works just as well, so if that's the preferred approach, I'll stick with that.
Which particular section of code were you interested in seeing? Where I implement saveInBackgroundWithBlock?
By the entire stacktrace, do you mean the stacktrace that was showing when I dropped down Thread 1 in the debugging console?
1) got it.
2) it's a rather large, complex operation and involves a method call that does JSON to core data mapping. i can't really post it all for confidentiality reasons, but i'm happy to post those sections of it that might be "sticky".
3) ok. is there a way to output that to a file or something or the best bet just to display it and screenshot it?
Also, the best bet is to paste any code/logs/backtraces into http://gist.github.com and pop the links back on this issue.
Hi @robreuss — I’m going to close this issue due to a lack of activity, but feel free to re-open it if this issue is ongoing. I hope you got it sorted out.