That makes sense. This particular inspector is fairly simple, but it does use one other Omni component on it: some OUIColorComponentSlider objects. If the crash that Omni have seen was also with inspectors using that class, then that would point towards that doing something wrong.
I’m kind of tempted to just take this to Omni guys rather than take everyone’s time, but I think there may be something here of general applicability if something comes out of this on either how to track this kind of memory issue down when it does happen, or lessons on how to prevent it... Regards Gideon On 15 Jan 2014, at 6:23 pm, Ken Thomases <k...@codeweavers.com> wrote: > On Jan 15, 2014, at 1:56 AM, Kyle Sluder wrote: > >> On Jan 14, 2014, at 9:05 PM, Quincey Morris >> <quinceymor...@rivergatesoftware.com> wrote: >>> >>> Second, I’ve noticed some very surprising behavior with weak references at >>> dealloc time. If an object being deallocated has a weak reference to >>> another object, and it was the only reference so that the other object is >>> also due to be deallocated […] > > That doesn't make sense. A weak reference can't be the only reference to an > object. As I'm sure you know, objects are deallocated (and weak references > nil'd) when the last *strong* reference is broken. > > Whatever the mysterious behavior is, I don't think it can be that. > > I suppose it could be that the object has a weak reference to itself and that > could cause some sort of problem if a message were sent through that weak > reference during -dealloc. I would expect that having a weak reference to > self would be fairly common and that ARC would have to cope properly. > > Since the original crash was an access violation inside the runtime, I would > suspect a memory smashing bug prior to the destruction of the > OUIInspectorPane subclass instance. When ARC goes to unregister that > instance's weak reference, it steps on a land mine that was laid previously. > Since the crash seems not to happen at random, I guess the memory smashing > was done shortly before this. (It's certainly possible for a corrupted data > structure to not influence anything until a long time after the corruption > has happened, but in that situation the crash is more likely to affect random > other code.) So, I'd suspect the -dealloc of the OUIInspectorPane subclass, > prior to the implicit call of super's -dealloc. Or the code which does the > final release of that object which provokes the deallocation. > > Regards, > Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
