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: Alex Zavatone <email@hidden>
- Date: Tue, 09 Feb 2016 09:58:38 -0500
On Feb 8, 2016, at 5:10 PM, Jens Alfke wrote:
>
>> 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.
>
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 (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