On Apr 7, 2015, at 3:13 PM, Jens Alfke wrote: > >> On Apr 7, 2015, at 7:04 AM, Alex Zavatone <z...@mac.com> 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 (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
