RestKit block copy semantics - sometimes causes random crashes #738

rbishop-xx opened this Issue May 12, 2012 · 1 comment


None yet
2 participants

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.

blakewatters added a commit that referenced this issue May 16, 2012


blakewatters commented May 16, 2012

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment