141

In ARC enabled code, how to fix a warning about a potential retain cycle, when using a block-based API?

The warning:
Capturing 'request' strongly in this block is likely to lead to a retain cycle

produced by this snippet of code:

ASIHTTPRequest *request = [[ASIHTTPRequest alloc] initWithURL:...

[request setCompletionBlock:^{
    NSDictionary *jsonDictionary = [[CJSONDeserializer deserializer] deserialize:request.rawResponseData error:nil];
    // ...
    }];

Warning is linked to the use of the object request inside the block.

barfoon
  • 25,436
  • 24
  • 88
  • 136
Guillaume
  • 21,205
  • 6
  • 60
  • 95
  • 1
    You should probably be using `responseData` instead of `rawResponseData`, check ASIHTTPRequest documentation. – 0xced Sep 05 '11 at 13:34

7 Answers7

164

Replying to myself:

My understanding of the documentation says that using keyword block and setting the variable to nil after using it inside the block should be ok, but it still shows the warning.

__block ASIHTTPRequest *request = [[ASIHTTPRequest alloc] initWithURL:...

[request setCompletionBlock:^{
    NSDictionary *jsonDictionary = [[CJSONDeserializer deserializer] deserialize:request.responseData error:nil];
    request = nil;
// ....

    }];

Update: got it to work with the keyword '_weak' instead of '_block', and using a temporary variable:

ASIHTTPRequest *_request = [[ASIHTTPRequest alloc] initWithURL:...
__weak ASIHTTPRequest *request = _request;

[request setCompletionBlock:^{
    NSDictionary *jsonDictionary = [[CJSONDeserializer deserializer] deserialize:request.responseData error:nil];
    // ...
    }];

If you want to also target iOS 4, use __unsafe_unretained instead of __weak. Same behavior, but the pointer stays dangling instead of being automatically set to nil when the object is destroyed.

Guillaume
  • 21,205
  • 6
  • 60
  • 95
  • Still would like to understand why the first solution doesn't work. – Guillaume Aug 26 '11 at 13:34
  • 8
    Based on the ARC docs, sounds like you need to use __unsafe_unretained __block together to get the same behavior as before when using ARC and blocks. – Hunter Sep 06 '11 at 21:20
  • You can combine the first two lines: `__weak ASIHTTPRequest * request = [[ASIHTTPRequest alloc] ...` – Sean Clark Hess Sep 22 '11 at 08:13
  • 4
    @SeanClarkHess : When I combine the first two lines, I get this warning: "Assigning retained object to weak variable; object will be released after assignment" – Guillaume Oct 07 '11 at 15:26
  • I am getting he same thing @Guillaume, did you find a solution? – Chris Wagner Oct 12 '11 at 21:20
  • @ChrisWagner My code after "Update: got it to work" compiles without warning. What is your problem? – Guillaume Oct 13 '11 at 09:02
  • 1
    @Guillaume thanks for the response, some how I overlooked the temporary variable, tried that and the warnings are gone. Do you know why this works? Is it just tricking the compiler to suppress the warnings or is the warning actually no longer valid? – Chris Wagner Oct 13 '11 at 22:54
  • Be careful with the second code. The `request` weak variable inside your completion block will most likely be `nil` by the time your block executes. I haven't found an elegant solution to this as well though, so I'm just ignoring the warning for now.. – John Estropia Nov 05 '11 at 11:13
  • @erurainon After seeing your response I am wondering now if the "Update: got it to work" is actually the proper way to do this. How can you safely refer to and use the request object within the block here? – barfoon Jan 14 '12 at 02:07
  • 2
    I've posted a follow up question: http://stackoverflow.com/questions/8859649/asihttprequest-asiformdatarequest-referencing-request-object-within-blocks-u – barfoon Jan 14 '12 at 02:23
  • 3
    Can someone explain why you need the __block and __weak keywords? I guess there is a retain cycle being created, but I do not see it. And how does creating a temporary variable fix the problem? – user798719 Nov 01 '12 at 20:41
50

The issue occurs because you're assigning a block to request that has a strong reference to request in it. The block will automatically retain request, so the original request won't deallocate because of the cycle. Make sense?

It's just weird because you're tagging the request object with __block so it can refer to itself. You can fix this by creating a weak reference alongside it.

ASIHTTPRequest *request = [[ASIHTTPRequest alloc] initWithURL:...];
__weak ASIHTTPRequest *wrequest = request;

[request setCompletionBlock:^{
    NSDictionary *jsonDictionary = [[CJSONDeserializer deserializer] deserialize:wrequest.rawResponseData error:nil];
    // ...
    }];
ZaBlanc
  • 4,631
  • 1
  • 32
  • 37
  • __weak ASIHTTPRequest *wrequest = request; did not work for me. Giving error I used __block ASIHTTPRequest *blockRequest = request; – Ram G. Jun 21 '18 at 20:52
13

It causes due to retaining the self in the block. Block will accessed from self, and self is referred in block. this will create a retain cycle.

Try solving this by create a weak refernce of self

__weak typeof(self) weakSelf = self;

operationManager = [[AFHTTPRequestOperation alloc] initWithRequest:request];
operationManager.responseSerializer = [AFJSONResponseSerializer serializer];
[operationManager setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {

    [weakSelf requestFinishWithSucessResponseObject:responseObject withAFHTTPRequestOperation:operation andRequestType:eRequestType];

} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
    [weakSelf requestFinishWithFailureResponseObject:error withAFHTTPRequestOperation:operation andRequestType:eRequestType];
}];
[operationManager start];
HDdeveloper
  • 4,257
  • 6
  • 38
  • 65
6

Some times the xcode compiler has problems for identifier the retain cycles, so if you are sure that you isn't retain the completionBlock you can put a compiler flag like this:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-retain-cycles"
#pragma clang diagnostic ignored "-Wgnu"

-(void)someMethod {
}
GOrozco58
  • 1,074
  • 12
  • 9
  • 1
    Some might argue that it is bad design but I sometimes create independent objects that hang out in memory until they are finished with an asynchronous task. They are retained by a completionBlock property which contains a strong reference to self, creating an intentional retain cycle. The completionBlock contains self.completionBlock=nil, which releases the completionBlock and breaks the retain cycle, allowing the object to be released from memory once the task is complete. Your answer is useful to help quiet the warnings that occur when I do this. – hyperspasm Feb 06 '15 at 20:46
  • 1
    to be honest, chances of one being right and the compiler being wrong are very small. So I'd say just surpassing the warnings is risky business – Max MacLeod Nov 09 '15 at 11:33
3

When I try the solution provided by Guillaume, everything is fine in Debug mode but it crashs in Release mode.

Note that don't use __weak but __unsafe_unretained because my target is iOS 4.3.

My code crashs when setCompletionBlock: is called on object "request" : request was deallocated ...

So, this solution works both in Debug and Release modes :

// Avoiding retain cycle :
// - ASIHttpRequest object is a strong property (crashs if local variable)
// - use of an __unsafe_unretained pointer towards self inside block code

self.request = [ASIHttpRequest initWithURL:...
__unsafe_unretained DataModel * dataModel = self;

[self.request setCompletionBlock:^
{
    [dataModel processResponseWithData:dataModel.request.receivedData];        
}];
squall2022
  • 214
  • 4
  • 9
2
ASIHTTPRequest *request = [[ASIHTTPRequest alloc] initWithURL:...
__block ASIHTTPRequest *blockRequest = request;
[request setCompletionBlock:^{
    NSDictionary *jsonDictionary = [[CJSONDeserializer deserializer] deserialize:blockRequest.responseData error:nil];
    blockRequest = nil;
// ....

}];

what the difference between __weak and __block reference?

Community
  • 1
  • 1
Emil Marashliev
  • 238
  • 2
  • 12
-6

Take a look at the documentation on the Apple developer website : https://developer.apple.com/library/prerelease/ios/#documentation/General/Conceptual/ARCProgrammingGuide/Introduction.html#//apple_ref/doc/uid/TP40011029

There is a section about retain cycles at the bottom of the page.

Nyx0uf
  • 4,519
  • 1
  • 23
  • 26