Re: Assuring KVO compliance.
Re: Assuring KVO compliance.
- Subject: Re: Assuring KVO compliance.
- From: Alex Zavatone <email@hidden>
- Date: Tue, 07 Apr 2015 15:24:51 -0400
On Apr 7, 2015, at 3:13 PM, Jens Alfke wrote:
>
>> On Apr 7, 2015, at 7:04 AM, Alex Zavatone <email@hidden> wrote:
>>
>> The code that I've inherited has an enum (not an NSEnum) that represents the app's connected state, 0, 1 or 2.
>
> There’s no difference. NS_ENUM is just a macro that defines a C enum, but uses some newer (C99?) syntax to specify the integer size that the enum should use. (Without that, if you just define a plain enum its size will be sizeof(int), IIRC.)
>
>> Results in this:
>> Thread1: EXC_BAD_ACCESS (code=1,address = 0x003f8f3)
>
> That’s not a useful crash report. All it says is “something accessed an invalid memory address." At a bare minimum you should show the top few lines of the stack down to your application code.
>
> I wouldn’t expect any sort of problem with a property that’s an enumerated type. I’ve done it often, and there are a lot of properties like that in UIKit, for example. But without a backtrace there’s no way of knowing why this failed.
Thanks. I didn't want to flood the list with extra data, but it appears I should have in this case.
>> To answer my own question, changing the enum to an NSInteger backed NS_Enum resulted in no more bad access exceptions from other chunks of code attempting to change the APP_State property.
>
> So, all you did was change the integer size of the value and the crash went away. This smells rather like there’s a bug lurking elsewhere in the app code that just happened to go away because of some slight change in the alignment of the value or the code being generated.
Thanks. That's what I was afraid of.
> If I were you I’d back out that change and debug what the actual crash is coming from.
With over 100 cases of @catch (NSException *exception) in this project, I think you're many times more right than you know.
We've got LOADS of cases of using the appDelegate as a hold-all for most everything and the appDelegate is referred to many times in many methods in many classes.
Lots of 2011 style interface and @property definition as well where the ivar is declared in the interface and then the @property is and then @synthesized.
Basically, with all that's obviously out of the ordinary here, I'm looking for a good strategy to find the most salient path to identifying the issue here and refactoring/modernizing as I go along.
The first step, I guess, is recreating the exception in a fresh copy of the project.
Thanks much to you and Quincey. I hope to get more on this to indicate an appropriate culprit and path.
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