Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fetcherCompletion is assign #1565

Closed
FindCrt opened this issue Jul 20, 2018 · 6 comments
Closed

fetcherCompletion is assign #1565

FindCrt opened this issue Jul 20, 2018 · 6 comments
Assignees
Milestone

Comments

@FindCrt
Copy link

@FindCrt FindCrt commented Jul 20, 2018

@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
Copy link
Member

@paulb777 paulb777 commented Aug 18, 2018

@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
Copy link
Contributor

@morganchen12 morganchen12 commented Aug 19, 2018

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

@paulb777
Copy link
Member

@paulb777 paulb777 commented Aug 19, 2018

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

@morganchen12
Copy link
Contributor

@morganchen12 morganchen12 commented Aug 19, 2018

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

@morganchen12 morganchen12 self-assigned this Aug 20, 2018
@paulb777 paulb777 added this to the M32 milestone Aug 21, 2018
paulb777 added a commit that referenced this issue Aug 24, 2018
paulb777 added a commit that referenced this issue Aug 24, 2018
paulb777 added a commit that referenced this issue Aug 24, 2018
@andrewehab

This comment was marked as spam.

@BlakeBoxberger
Copy link

@BlakeBoxberger BlakeBoxberger commented Aug 20, 2019

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.

@firebase firebase locked and limited conversation to collaborators Oct 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants