mikeash.com pyblog/friday-qa-2010-07-16-zeroing-weak-references-in-objective-c.html comments

Minh Nguyen - 2021-05-25 04:26:22

Tue, 25 May 2021 04:26:22 GMT

It is state that:

- (void)setFoo: (id)newFoo
{
_foo = newFoo;
}
Because the setter does not use retain, the reference does not keep the new object alive. It will stay alive as long as it's retained by other references, of course. But once those go away, the object will be deallocated even if _foo still points to it.”

Excerpt From: Mike Ash. “The Complete Friday Q&A: Volume 1.” Apple Books.

But in ARC, I think an instant variable hold a strong reference. Which means that _foo keep hold of the memory of newFoo, right.
Please explain me this ?

Keith - 2015-09-14 20:18:20

Mon, 14 Sep 2015 20:18:20 GMT

In CustomSubclassRelease, shouldn't WhileLocked surround the entire function? The call to GetRealSuperclass calls GetCustomSubclass which accesses the shared variable gCustomSubclasses.

Larry - 2015-01-05 14:08:50

Mon, 05 Jan 2015 14:08:50 GMT

Can this be used for references in UIKit frameworks such as UIGestureRecognizer that may be internally referencing their delegate properties by iVars?

mikeash - 2013-05-29 14:46:49

Wed, 29 May 2013 14:46:49 GMT

The problem with swizzling dealloc is that it will affect every instance of that class, even ones that are not weakly referenced.

For a worst case scenario, consider allocating a plain NSObject instance, and then creating a weak reference to it. With that approach, you've now swizzled -[NSObject dealloc], meaning that every single object in the system is going through custom code, causing a potentially large performance impact, and increasing the chances of an unfortunate interaction with other code.

François Lamboley - 2013-05-29 10:26:41

Wed, 29 May 2013 10:26:41 GMT

Great article! However, instead of isa-swizzling, couldn't you have used method_exchangeImplementations() for the dealloc and release methods? You can call the original implementations from your implementations.
It seems highly easier to use rather than creating a dynamic subclass, and may solve all of the KVO/CF problems.

mikeash - 2013-04-03 14:49:49

Wed, 03 Apr 2013 14:49:49 GMT

A recursive lock is functionally identical to a lock that ignores locks/unlock pairs on a thread that already has the lock.

René Bertin - 2013-03-29 16:26:58

Fri, 29 Mar 2013 16:26:58 GMT

Probably a naive question: why use a recursive (global) mutex? Just so you can lock/release it from a thread that already owns a lock on it? Is that better than a mutex variant which makes a lock and the matching release noops when executed by a thread that already has the lock?

mikeash - 2011-10-03 03:42:29

Mon, 03 Oct 2011 03:42:29 GMT

Yep, that code looks good. In fact, this is a fairly common use case for this library in my experience. It's really easy to make retain cycles with blocks, and hard to deal with non-zeroing weak references in their place. Zeroing weak references make everything much easier.

Ben G. - 2011-10-02 23:53:02

Sun, 02 Oct 2011 23:53:02 GMT

Mike, this is some fascinating stuff.

Just so I'm sure I understand the interaction of MAZeroingWeakRef and blocks' implicit retaining behavior, is the following a valid way to create a block that:

1) References self or an ivar of self, and
2) Can be copied and stored inside self (or an object retained by self) without creating a retain cycle, and
3) No-ops if self is dealloc'ed before the block is invoked (say, via a copy stored in another object)

?



@interface Foo : NSObject

@property (copy) void (^block)();

@end



@implementation Foo



@synthesize block = _block;



- (void)foo {

   MAZeroingWeakRef* weakSelf = [[[MAZeroingWeakRef alloc] initWithTarget:self] autorelease];



  self.block = ^{

    [[weakSelf target] bar];

  };

}



- (void)dealloc {

  self.block = nil;

  [super dealloc];

}



@end

mikeash - 2011-03-21 19:34:33

Mon, 21 Mar 2011 19:34:33 GMT

I'm not sure if I've understood you correctly, but any class methods that you don't override will go to the parent class's implementation, since inheritance works at the class level as well as the instance level.

mark - 2011-03-21 18:52:56

Mon, 21 Mar 2011 18:52:56 GMT

Is there anyway to forward class messages to the parent class when a dynamic subclass is created? I'm using resolveInstanceMethod: to support dynamic properties. I've hacked the code to call just that one, but there might be other class methods that no longer work properly once a dynamic subclass is created.

mikeash - 2011-03-16 20:57:14

Wed, 16 Mar 2011 20:57:14 GMT

otx is really useful. Its annotations are a huge help for bridging the gap between seeing assembly as gibberish and understanding it top to bottom.

Chase - 2011-03-16 18:58:12

Wed, 16 Mar 2011 18:58:12 GMT

Thanks. I got to step 5, and was lost thereafter. Thanks for the pointer to otx, and thanks for giving us so many useful classes!

mikeash - 2011-03-16 17:48:20

Wed, 16 Mar 2011 17:48:20 GMT

Here's a rough reconstruction of my steps.

1. Run the test, watch it crash. Notice that it's crashing because it's accessing a deallocated object.
2. Something must be going wrong with CustomSubclassDealloc to cause the weak reference not to be zeroed. Put a breakpoint there to see what happens.
3. Run the test again, breakpoint is not hit. Odd.
4. Add a stub dealloc method to KVOTarget to see if that is firing. Breakpoint on that to see what happens.
5. That breakpoint is hit. It is not being called from CustomSubclassDealloc, but rather from a private Foundation function called NSKVODeallocate.
6. Check out the annotated disassembly of that function from otx. Notice that it invokes my dealloc by fetching the IMP using class_getInstanceMethod. Immediately before that call is a call to object_getIndexedIvars.
7. Put a breakpoint on object_getIndexedIvars with the program stopped just before destroying target. Run, hit the breakpoint. Print the argument to object_getIndexedIvars, and find that it's the KVO subclass.
8. Guessing, I print *(id *)object_getIndexedIvars(KVO subclass) and discover that it's KVOTarget.
9. Write code to overwrite that with the intermediary class, run it, tests all pass, decide it's good.

Chase - 2011-03-16 17:00:04

Wed, 16 Mar 2011 17:00:04 GMT

No problem, thanks for the fix! If you don't mind me asking, how did you come up with the fix for the crash I reported? I kind of figured it was being caused by KVO not respecting the runtime class hierarchy, but after that I had no idea where to proceed in trying to fix it.

mikeash - 2011-03-16 15:05:04

Wed, 16 Mar 2011 15:05:04 GMT

Thanks a lot for that. I've fixed it. Your "NoCrash" test also revealed another KVO-related bug due to an ordering dependency in when subclasses are created. I assume you didn't encounter it because you ran your tests in a different order from mine. Fixes for both are now up on github.

Chase - 2011-03-16 02:31:32

Wed, 16 Mar 2011 02:31:32 GMT

I've found another problem with MAZeroingWeakReference and KVO, unfortunately. I've posted a gist with two tests, one which crashes, and another which passes. The crash occurs when a KVO object is released, and you subsequently try to use the target of the ref. If the KVO subclass was created first, the crash will occur when dereferencing _target. If the target is embedded in an MAZeroingWeakRef first, and then KVO observed, no crash occurs.

The gist is available here: https://gist.github.com/871905#file_ma_zeroing_weak_ref%20kvo%20crash%20test

mikeash - 2011-01-07 16:27:10

Fri, 07 Jan 2011 16:27:10 GMT

One problem with that is that it won't work on classes which implement their own reference counting mechanism, which while not exactly common, is not entirely unheard of either. Inline reference counting can be a nice little performance boost for objects that get retained and released with high frequency.

Andrew - 2011-01-07 05:44:47

Fri, 07 Jan 2011 05:44:47 GMT

What is everyone's opinion on this approach?

At startup, store NSObject's -release IMP somewhere and set it to your own function. In your function, check [self retainCount]. If retainCount is 1, then the object is doomed and will be deallocated upon calling NSObject's original IMP for -release.

mikeash - 2010-09-18 19:39:34

Sat, 18 Sep 2010 19:39:34 GMT

Thanks very much for the bug report. I've applied your recommended fix in the project on github:

http://github.com/mikeash/MAZeroingWeakRef

Due to the difficulty of maintaining both repositories, I am not currently maintaining the Subversion repository with fixes like this. If there's demand for it I'll get them synced up, but github seems to be a better place to keep this anyway.

Jason - 2010-09-18 18:58:37

Sat, 18 Sep 2010 18:58:37 GMT

Mike,

Again, thank you for this excellent pair of classes. It has come in handy in a number of situations.

Recently I have discovered a bug in MAZeroingWeakProxy, however. The usual program flow appears to go through "forwardingTargetForSelector:".

However, if the weak target has been deallocated, this will return nil, so the message goes through "forwardInvocation:". This works correctly, except for delegate-style messages returning void. I had come across a bug whereby the internals of NSInvocation was crashing because that method's "returnLength" was zero, and NSInvocation's "setReturnValue:" was crashing because of it (it calls setArgument:atIndex: which then calls __NSI2, __NSI0, and crashes).

Simply wrapping those three lines in an "if (returnLength > 0)" block avoids the crash.

mikeash - 2010-08-16 23:19:22

Mon, 16 Aug 2010 23:19:22 GMT

Thinking about it more, I believe a better solution would be to swizzle out the KVO subclass's implementation of - release and -dealloc and basically have a separate override path for them. This would prevent the KVO subclass from doing anything bad in release or dealloc. However, I can't think of a specific example, and I believe this probably can't actually happen in practice.

Shirui - 2010-08-16 23:03:25

Mon, 16 Aug 2010 23:03:25 GMT

Yeah, that's what I did as well... Sigh... Looking for a better (more fool-proof) solution though...

mikeash - 2010-08-16 22:15:47

Mon, 16 Aug 2010 22:15:47 GMT

And fixed. I solved it by inserting the ZWR subclass above the KVO subclass. This is horrible, but it does the job.

The fix is up on github, but not yet in Subversion, as I have run into trouble getting them to communicate now.

Shirui - 2010-08-16 21:50:05

Mon, 16 Aug 2010 21:50:05 GMT

Well, I was easily able to reproduce the problem like this:

1. Create a new Xcode project. (The App Delegate should be automatically generated for you.)
2. Open up the default XIB file and add an NSTextField to it, bound to some property of the App Delegate.
3. Declare the appropriate property in the App Delegate so that the binding works.
4. In -applicationDidFinishLaunching:, query object_getClass(self) and ensure that it's the NSKVONotifying version. Then, do the custom subclassing and query the object, i.e., [self description] and [self class] to see that you get junk values.

Unfortunately, KVO is such a common case (bindings!) that I at least won't be able to use Weak Referencing until we can make it be friends with KVO. :-/

mikeash - 2010-08-16 21:21:45

Mon, 16 Aug 2010 21:21:45 GMT

I have now reproduced the problem, or at least a problem. It doesn't manifest until you actually call an observed setter, or at least it didn't for me. It appears that the problem lies in KVO assuming that self->isa is the KVO class, and calling object_getIndexedIvars on it. I'm investigating to see if this problem can somehow be mitigated in the general case. Overriding automaticallyNotifiesObserversForKey: to always return NO and doing manual notification should be a decent workaround though.

mikeash - 2010-08-16 20:06:27

Mon, 16 Aug 2010 20:06:27 GMT

That is really odd. I was afraid of KVO subclasses getting screwed up, but a quick test doesn't show any problems. The only way I can possibly see that your class could end up as 0x0 after object_setClass is if you're passing nil to that function to begin with.

Would it be possible for you to produce a small test case that shows the problem? My KVO test case is up on my svn and github if you want to compare with it.

Shirui - 2010-08-16 05:38:09

Mon, 16 Aug 2010 05:38:09 GMT

Hmm... you might be right. I've yet to actually check whether retainCount indeed returns 0 when the object is in -dealloc.

In the meanwhile though, I've found a more concerning issue. It looks like the custom subclasses that KVO makes do not like to be subclassed. I was seeing some random crashes in CFEqual recently and traced the problem down to the fact that one of my object's class information was getting corrupted when its class was changed to be a weak reference.

Here's briefly what I got in the debugger:

BEFORE object_setClass is called:
> po [object class]
AppDelegate
> po currClass
NSKVONotifying_AppDelegate
> po customSubclass
NSKVONotifying_AppDelegate_WeakReferenceable

And just AFTER object_setClass is called:
> po [object class]
0x0
> po object
<not an object or object does not respond to description method>

This is very disturbing and I'm not sure exactly what's going wrong. Have you seen anything like this? Any ideas?

mikeash - 2010-08-13 02:41:23

Fri, 13 Aug 2010 02:41:23 GMT

You can't really check for retainCount > 0, because that never happens. Cocoa reference counting is optimized to not store an entry for objects with a retain count of 1, so any object without a retain count entry is assumed to have a count of 1. When you release an object with a count of 1, it is destroyed, but it never gets an entry to say that its count is 0, because, well, it's being destroyed.

I suppose I could maintain a collection of weak refs that are in the middle of destruction and assert that nobody tries to resurrect them, but I think that with the two-stage zeroing/cleanup process, it's not really needed.

Shirui - 2010-08-13 00:26:10

Fri, 13 Aug 2010 00:26:10 GMT

It eventually comes down to the same thing as "resurrection" in the GC world, wherein if you have snuck away a pointer to object A somewhere, you can try to make a new weak pointer to it during A's dealloc, inside your cleanup block. There are no clear safeguards against it, but at the least you can add a check for retainCount > 0, before you agree to make a weak ref out of an object.

mikeash - 2010-08-12 20:55:30

Thu, 12 Aug 2010 20:55:30 GMT

After more thought, I decided that splitting weak ref cleanup into two stages makes a lot of sense. It makes it much easier to write safe cleanup blocks and eliminates the potential for some ugly bugs. I've gone ahead and made that change and committed it.

mikeash - 2010-08-12 20:13:40

Thu, 12 Aug 2010 20:13:40 GMT

If you create a new weak reference to the target in your cleanup block, I would consider that to be a bug.

However, in a program with complicated object graphs, it may not be easy to realize what you're doing. This is why you should keep your cleanup block minimal.

I'm starting to think that zeroing the target and calling the cleanup block should happen in two passes. Pass one, zero all targets. Pass two, execute cleanup blocks for anything that needs it. That will ensure that you can't accidentally make new references to the target (or accidentally resurrect the target through an existing weak reference), as the target parameter will be the only way you could possibly get to it.

I'll have to think about this....

Shirui - 2010-08-12 18:34:21

Thu, 12 Aug 2010 18:34:21 GMT

Hmm, OK, another edge case: in ClearWeakRefsForObject, you make a copy of the set to ensure that you are not iterating over a set that's being mutated. Now, what if, as part of the cleanup block, someone goes and creates a weak reference to the object for which ClearWeakRefsForObject is being called? It looks like the new value would get added to the set, but the set would get removed from the dictionary at the end of ClearWeakRefsForObject, leaving a dangling pointer behind in this brand new weak ref...

Potential fixes: when you enter ClearWeakRefsForObject, poison the object that you are entering for and make sure no new refs get added for it.

mikeash - 2010-08-11 04:45:45

Wed, 11 Aug 2010 04:45:45 GMT

Right, I'm basically expanding the scope of what needs to be atomic, so I have to add my own mutex to the mix.

If you are leaving out cleanup blocks then you won't need to duplicate the set, as without them, there is nothing that _zeroTarget can do to cause the set to mutate.

Shirui - 2010-08-10 21:04:41

Tue, 10 Aug 2010 21:04:41 GMT

Thanks for the clarification! I was referring to the mutex around the call to -retain in -target, but I see why that's necessary now. I also understand your argument about -release and -retain being thread-safe on their own, but the fact that you want to make sure the operation of "release and nil out references if necessary" is atomic as a whole. Am I right?

Also, I'm guessing (correctly, I hope) that I don't need to duplicate the set for my implementation because I am not using a cleanup block and so it should not be the case that something is enumerating over the set while the another thing is mutating it.

mikeash - 2010-08-10 19:06:58

Tue, 10 Aug 2010 19:06:58 GMT

The mutex around the release (I don't think there's one around retain) is to prevent a race condition that would appear otherwise. Imagine this scenario: thread A releases the last strong reference. Thread B uses a weak reference. Thread A destroys the object. Thread B accesses the destroyed object, crashing.

The mutex prevents this from happening. Essentially, Apple's code is thread safe but the code I add on to it is not unless I add a mutex to it as well. Thread safety is often tricky like that: X can be thread safe, and Y can be thread safe, but the combination of X+Y may not necessarily be thread safe without taking additional action.

As for copying the set, it is possible for a cleanup block to mutate the set of weak references on the object, which then causes an enumeration mutation exception. (It is forbidden to mutate a collection while enumerating over it in Cocoa.) Thus I make a copy of the set to ensure that it doesn't get mutated during enumeration. See TestCleanupBlockReleasingZWR in main.m for an example of how that could happen.

Shirui - 2010-08-10 18:20:24

Tue, 10 Aug 2010 18:20:24 GMT

Just read through the entry and all the comments. Brilliant work! Thank you!

A couple of questions though:

1. According to the thread-safety summary on Apple's Developer site (http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html#//apple_ref/doc/uid/10000057i-CH12-SW1), "Object allocation and retain count functions" and "Zone and memory functions" are thread-safe. Why then do we need a mutex around the call to release and retain?

2. In ClearWeakRefsForObject, why make a copy of the set instead of taking a mutex around it like everywhere else?

Thanks!

mikeash - 2010-07-23 01:08:44

Fri, 23 Jul 2010 01:08:44 GMT

I've now fixed the code to build without blocks, by making WhileLocked a macro. I've also fixed the problem found by Steve Brambilla which could cause a mutation exception while zeroing out targets. These changes are in my repository.

Thanks very much to both of you for finding these problems, and Jason, it's very neat to hear how you've used this stuff to solve your problem.

mikeash - 2010-07-23 00:21:50

Fri, 23 Jul 2010 00:21:50 GMT

Duh, I forgot that WhileLocked would cause problems on blockless OSes. I should probably macroize it so it can work on older systems.

Jason - 2010-07-22 22:43:23

Thu, 22 Jul 2010 22:43:23 GMT

Thanks again for this. Fully integrated it, and it works beautifully. The proxy is deallocated with the UIWebView, and the zeroing ref's target was nil as intended.

The only catch was that I had to "insert" the contents WhileLocked, since I am targeting blockless iOS 3.2.

mikeash - 2010-07-20 01:13:22

Tue, 20 Jul 2010 01:13:22 GMT

That's why the check is different (better, as far as I know 100% reliable) if COREFOUNDATION_HACK_LEVEL is set to 1 or 2.

If you or anyone else should happen to know of a better way to check for TFBness without using private CF API or doing a lame check for an NSCF prefix, I'd be very interested to know. I was not able to find any such way when I built this, but that doesn't mean it's not possible.

Ned Holbrook - 2010-07-19 18:10:00

Mon, 19 Jul 2010 18:10:00 GMT

On the toll-free bridging front, I would note that there are bridged classes that your check won't catch: NSFont/CTFont{Descriptor} comes to mind.

mikeash - 2010-07-19 11:20:36

Mon, 19 Jul 2010 11:20:36 GMT

The original set is specially constructed not to retain its contents, and the copy probably keeps that attribute. You could fix it by replacing the copy with [[NSSet alloc] initWithSet: (NSSet *)set]. Then you wouldn't have to manually retain/release the contents.

Steve Brambilla - 2010-07-19 02:57:50

Mon, 19 Jul 2010 02:57:50 GMT

Replacing it with this code works:



static void ClearWeakRefsForObject(id obj)

{

    CFMutableSetRef set = (void *)CFDictionaryGetValue(gObjectWeakRefsMap, obj);



    NSSet *setCopy = [(NSSet *)set copy];

    [setCopy makeObjectsPerformSelector: @selector(retain)];

    [setCopy makeObjectsPerformSelector: @selector(_zeroTarget)];

    [setCopy makeObjectsPerformSelector: @selector(release)];

    [setCopy release];



    CFDictionaryRemoveValue(gObjectWeakRefsMap, obj);

}

Without the extra retain / release messages the objects can be deallocated while it's enumerating sending _zeroTarget. But I don't completely understand why; shouldn't setCopy already retain them?
Sending the extra retain / release messages feels sloppy...

mikeash - 2010-07-19 01:12:19

Mon, 19 Jul 2010 01:12:19 GMT

Nice catch. I think the answer is to enumerate over a copy of the set rather than the original. That will hurt performance slightly, but will allow cleanup code to mutate the set. I don't have time to make the modification right now, but it should be a simple matter of sticking a copy and release in the method in question. I will get to it at some point....

Steve Brambilla - 2010-07-18 23:16:54

Sun, 18 Jul 2010 23:16:54 GMT

I figured it may have been used for something like that.

The other thing that I've observed is a rare set mutation while enumerating exception in ClearWeakRefsForObject. This is what I think is happening: it occurs if the cleanup block releases another instance of MAZeroingWeakRef that has its target set to the object being deallocated. When the MAZeroingWeakRef is deallocated RemoveWeakRefFromObject gets called, which mutates the set that is still being enumerated by makeObjectsPerformSelector:.

I observed this when I added another weak observer method to NSNotificationCenter to support blocks:



- (void)addWeakObserver:(id)observer forName:(NSString *)name object:(NSString *)object onQueue:(NSOperationQueue *)queue usingBlock:(void (^)(NSNotification *))block

{

    id observerToken = [self addObserverForName:name object:object queue:queue usingBlock:block];

    

    MAZeroingWeakRef *ref = [[MAZeroingWeakRef alloc] initWithTarget:observer];

    [ref setCleanupBlock: ^(id target) {

        [self removeObserver:observerToken];

        [ref autorelease];

    }];

}

And then used it something like this:



MAZeroingWeakRef *selfRef = [MAZeroingWeakRef refWithTarget:self];

[[NSNotificationCenter defaultCenter] addWeakObserver:self forName:MyNotification object:nil onQueue:nil usingBlock:^(NSNotification *note) {

    [[selfRef target] doWhatever];

}];

When NSNotificationCenter releases the block, the captured MAZeroingWeakRef gets deallocated while it's target is clearing its weak references.

I'm not sure the best way to handle a mutating set, but I presume that if the set could be enumerated while being mutated that it would solve this, or would there be some other side effect I've overlooked?

mikeash - 2010-07-18 19:47:42

Sun, 18 Jul 2010 19:47:42 GMT

Good catch. That's just a leftover from my earlier experiments with CF workarounds. (I was having some trouble and thought that CF might need to be poked to initialize some values.) I've removed it from the repository.

Steve Brambilla - 2010-07-18 19:28:14

Sun, 18 Jul 2010 19:28:14 GMT

Thanks a lot for this, I have already found it very useful over the past couple days.

In + initialize the line CFStringCreateMutable(NULL, 0); creates a mutable string that is never referenced or used. Can we safely remove this, or is it somehow part of the hackery?

Jason - 2010-07-17 20:30:11

Sat, 17 Jul 2010 20:30:11 GMT

The docs say:

The UIWebView class should not be subclassed.

So I'll stick with objc_setAssociatedObject and implement some category methods on UIWebView. Thanks again!

mikeash - 2010-07-17 18:51:26

Sat, 17 Jul 2010 18:51:26 GMT

If your OS requirement is iOS 3.1+, then you can use objc_setAssociatedObject to associate the proxy with the web view. Then it won't get deallocated until the web view does.

Another possibility: can you subclass UIWebView? If so, you could add the proxy as an instance variable, and release it in dealloc.

Jason - 2010-07-17 18:26:19

Sat, 17 Jul 2010 18:26:19 GMT

On looking at the source, it appears to be exactly what is called for. However, I fear that it may wind up having to leak the proxy in order to resolve the crash issue. The great thing is that it allows the real target to be released (of course), but to keep UIWebView from crashing I expect that I will need to keep the proxy object alive.

I can probably avoid a crash by releasing it after some time. I'd like to do something like this in my FooController:

// setup
webView = ...;
myProxy = [[MAZeroingWeakProxy alloc] initWithTarget:self];
webView.delegate = myProxy;

// dealloc
if (myProxy)
{
    [myProxy performSelector:@selector(description) withObject:nil afterDelay:60];
    [myProxy release];
    // Now, only NSObject has a strong reference.
}
webView.delegate = nil;

But of course, NSProxy doesn't support that method. I'd have to set up a non-repeating NSTimer, I think. Not the best, but I think it's the only way.

mikeash - 2010-07-17 18:08:36

Sat, 17 Jul 2010 18:08:36 GMT

Sure, and I'd be very interested in hearing how it works out for you.

Jason - 2010-07-17 18:01:02

Sat, 17 Jul 2010 18:01:02 GMT

Thanks so much!

mikeash - 2010-07-17 16:06:27

Sat, 17 Jul 2010 16:06:27 GMT

With all the talk about proxies, I went ahead and implemented one. MAZeroingWeakProxy is available in the subversion repository now. I still recommend using the explicit weak ref wherever it makes sense, but for things like faking out delegates for framework objects, the proxy is probably a better choice.

mikeash - 2010-07-17 15:11:08

Sat, 17 Jul 2010 15:11:08 GMT

That is nasty. An NSProxy subclass which bounces messages through a MAZeroingWeakRef should solve your problem, and is probably a nicer way to approach delegates/data sources for code you don't own in general. Attach the proxy to the UIWebView as an associated object (if you can require an OS version that has them) and you won't have to worry about memory management.

Jason - 2010-07-17 14:51:58

Sat, 17 Jul 2010 14:51:58 GMT

This is incredibly useful. We are having to implement a related utility class that solves this problem from another perspective -- when we aren't the ones calling into the delegate. Specifically, we have found that UIWebViews continue to send messages to their delegate even after setting their delegate to nil on the main thread.

It appears that because of JavaScript running on a timer, or something to that effect, there are cases whereby an Invocation has been queued up to send from a background web thread while the main thread is busy unsetting the UIWebView's delegate (because that object is being dealloc'ed). By the time the invocation makes it to the main thread, it attempts to send a message to the deallocated object.

Attempting to solve it through another proxy-like object like this one.

mikeash - 2010-07-17 13:50:58

Sat, 17 Jul 2010 13:50:58 GMT

Regarding the proxy idea, I thought about it, but decided against it because it's too easy to forget that your target can disappear in the middle of your code if you use a proxy. For example:



if([weakRef condition]) // alive here

    [weakRef doSomethingImportantWithObject: self]; // gone here

else

    [self doSomethingEquallyImportant]; // never gets here

Whereas with an explicit reference, you have to work very hard to create that problem. Normally you'd write:



id obj = [weakRef target]; // obj is now in autorelease pool, stays alive through the end of the code

if([obj condition]

    [obj doSomethingImportantWithObject: self];

else

    [self doSomethingEquallyImportant];

And you don't have to structure your code to tolerate having the object disappear in mid-stream.

As for the cleanup block, referring to target there is no more dangerous (and actually slightly safer) than referring to self in dealloc, which we do all the time. The notification example is semantically the same as the extremely common pattern of removing a notification observer in dealloc.

Ken Thomases - 2010-07-17 11:16:22

Sat, 17 Jul 2010 11:16:22 GMT

Oh, and don't you have to be extraordinarily careful in the cleanup block? Almost any reference to the target is dangerous.

First, there's the problem of resurrecting the object. This is especially likely if you reference the target in a deferred way, like you suggest.

Second, there's the problem that the target is partially dealloc'd already, in the case that KVO (or something else) has subclassed after MAZeroingWeakRef.

It's not clear to me that even your NSNotificationCenter(MAZeroingWeakRefAdditions) category is safe.

I almost think that you shouldn't support passing the target to the cleanup block. Or perhaps it would be passed as a uintptr_t so it can't accidentally be used as an actual object pointer.

Ken Thomases - 2010-07-17 10:51:59

Sat, 17 Jul 2010 10:51:59 GMT

Have you considered making MAZeroingWeakRef a proxy for its target?

mikeash - 2010-07-17 02:16:17

Sat, 17 Jul 2010 02:16:17 GMT

I want to mention further: I don't think that non-thread-safe zeroing weak references are useful in any general sense. They may work for specific situations, but it's far too easy to lose control of your object's lifetime and end up having it be deallocated on another thread without meaning to. Just capture an object in a block and pass it to GCD and you're toast.

Such zeroing weak references are easy to construct, and have been done before. What MAZeroingWeakRef brings to the table is that it is, as far as I know, the first such implementation that is thread safe, and therefore safe to use in the general case.

mikeash - 2010-07-17 02:00:35

Sat, 17 Jul 2010 02:00:35 GMT

Associated objects make zeroing weak references really easy if you don't care about thread safety. Unfortunately they're completely useless for thread-safe zeroing weak references.

The reason is object resurrection. You have to zero out all weak references to an object before that object's dealloc (or CF finalize function) executes, and any queries to a weak reference which return an object must prevent dealloc or finalize from executing at all.

By the time an associated object is freed, it's far too late to prevent the object it's associated with from being destroyed, so you end up with horrible race conditions.

This is why the pure ObjC override hits both release and dealloc; simply overriding dealloc isn't enough, as you end up with a race condition between the final call to release and the call to dealloc.

The CF craziness gets around it because pure CF objects are allowed to resurrect themselves in their finalize function, thus I override that and check for the condition where a weak reference has caused resurrection before proceeding with object destruction.

Clark Cox - 2010-07-17 00:21:32

Sat, 17 Jul 2010 00:21:32 GMT

I wonder if you've considered using objc_setAssociatedObject instead of class/method swizzling. That is, associate an object with the target object that, itself, gets released when the target object is deallocated. This may allow you to work with CF objects without needing any kind of hack or private-API calls