fetcherCompletion is assign

[FindCrt]

@property(readonly) GTMSessionFetcherCompletionHandler fetcherCompletion;

This property is using default assign, so fetcherCompletion will may be released to case a wild pointer and EXC_BAD_ACCESS crash.

In the file FIRStorageDownloadTask.m, there is a assignment for fetcherCompletion :

_fetcherCompletion = ^(NSData *data, NSError *error) {
      ......
};

And at the end of this scope, there is a fetch:

[self.fetcher beginFetchWithCompletionHandler:^(NSData *data, NSError *error) {
    weakSelf.fetcherCompletion(data, error);
  }];

Because this fetch is async, when weakSelf.fetcherCompletion calls, the temporary scope in which fetcherCompletion is assigned has gone. fetcherCompletion become a bad memory.

[paulb777]

@ToFind1991 Sorry for the delayed response.

Are you seeing a demonstrable issue with this code?

My understanding is that the weakSelf takes care of the issue that you're describing. When fetcherCompletion is deallocated along with its containing object, weakSelf will be set to nil and the function call will be a no-op.

[morganchen12]

To clarify the object being deallocated here isn't self, it's the fetcherCompletion closure. This should be copy and not assign.

[paulb777]

This stackoverflow answer seems to indicate that while copy is recommended for documentation, it's not functionally necessary when built with ARC.

[morganchen12]

strong will do too, but assign is hazardous since it doesn't provide any guarantees for ownership or deallocation.

[BlakeBoxberger]

It looks like this issue has somehow re-manifested itself. Even with the copy attribute, I'm getting EXC_BAD_ACCESS on this exact line.

EDIT: This can be avoided by using .observe() instead of .enqueue(). It should still be properly fixed, but I hope this suggestion helps anyone desperately searching for a fix like I was.