On Feb 8, 2016, at 5:10 PM, Jens Alfke wrote:
>
>> On Feb 8, 2016, at 1:47 PM, Alex Zavatone <z...@mac.com> wrote:
>>
>> if ( [myIVar respondsToSelector:@selector(someMethod)] {
>> EXC_BAD_ACCESS (code=1, address=0x143545358)
>> I did a po on myiVar and I get an address or 0x000000014f05ee00
>
> 0x143545358 is probably the (bogus) class-info pointer it got from the
> object’s ‘isa’ pointer. So in this case the myIVar pointer itself isn’t
> itself obviously bad, but it is pointing to garbage. Most likely it used to
> be a valid object but was dealloced and the memory’s been reused for
> something else.
>
> NSZombieEnabled is the obvious thing to try here. And/or the address
> sanitizer.
>
Arrrgh. This is not a trivial case to reproduce. Thanks for the tips though.
>> Also, I'd prefer to use the property not the iVar as I've found these much
>> safer in the past for accessing internal objects without causing access
>> issues.
>> Am I correct here?
>
> I always use ivars because it’s much more efficient in code size and clock
> cycles. The only case where using ivars directly can bite you is if either
> the ivar or the property will be modified on another thread, since ARC’s
> inlined setter code isn't thread-safe.
>
> But I always prefix ivars with an underscore to make it obvious that they
> have different scope from locals.
Yeah, something that kills me here. No camelcasing and identical ivar and
property names. : /
Thanks you, sir. As always, your input is much appreciated.
Alex Zavatone
_______________________________________________
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
