RestKit does not appear to call Block_copy() or [blockvar copy] on blocks that it stores beyond the lifetime of the function - e.g.: RKObjectMappingProvider+CoreData.m stores the block object in the userData field.
As a result if the block is a literal block that has closures, it is up to the caller to know that this particular RestKit API keeps a reference to the block beyond the normal lifetime but that other API does not (and assuming the caller knows the block is stack allocated in the first place - a lot don't because most APIs like GCD handle Block_copy automatically).
If there are no closures then the compiler just so happens to promote the block to a global literal and it will work by accident but we shouldn't depend on this behavior. I ran into this when I used a self reference that suddenly made the block a closure and caused the problem.
Further, under ARC there is no way to deal with these API calls without leaking or doing some really ugly bridge casts.
@property declarations should be good to go so long as they are declared copy and the setter isn't overridden incorrectly. From a cursory examination this appears to be all good but I haven't made extensive checks.
Add Block_copy() invocation to ensure the fetch request block is tran…
…sferred to the heap. refs #738
I did a quick audit by searching for "(^" across the code base. It looks like the CoreData.m file was the only offending reference that I could find.