Re: Just a quick verification on a bad access cause.
Re: Just a quick verification on a bad access cause.
- Subject: Re: Just a quick verification on a bad access cause.
- From: Jens Alfke <email@hidden>
- Date: Mon, 08 Feb 2016 14:10:42 -0800
> On Feb 8, 2016, at 1:47 PM, Alex Zavatone <email@hidden> 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.
> 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.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden