Re: -performSelector: exception... in one build configuration
Re: -performSelector: exception... in one build configuration
- Subject: Re: -performSelector: exception... in one build configuration
- From: Michael Babin <email@hidden>
- Date: Wed, 02 Nov 2011 07:51:38 -0500
On Nov 2, 2011, at 12:23 AM, Steve Christensen wrote:
> No, I don't think this is a Cocoa issue.
>
> I recently moved an app project from Xcode 3.2.6/iOS 4.3 to Xcode 4.2/iOS 5.0. The project is set up to build debug (no optimizations, debug-only status and error messages in the code), release (full optimization, code stripping, etc. for local testing), and distribution (same as release except for an app store distribution profile) configurations.
>
> Today I ran into something weird. My app includes a category on NSUserDefaults that adds some app-specific getter/setter methods. In most cases I'm just calling, e.g., [[NSUserDefaults standardUserDefaults] foo], but for one case I'm using [[NSUserDefaults standardUserDefaults] performSelector:@selector(foo)].
>
> This worked just fine for previous builds (all configurations) with Xcode 3.2.6, and works fine for simulator builds (debug/release) and device builds (debug), but crashes with an unknown selector exception for a release device build. While trying to track down what's going on, I added a NSLog call that prints the result of -respondsToSelector: for that message selector and it says that the selector exists for all the cases that don't crash, and that it doesn't exist for the case where it crashes.
>
> Note that there are several methods in the NSUserDefaults category that are also called in both ways, and except for one getter/setter pair, all of the direct method calls and -performSelector: calls work fine for all configurations.
>
> Does anyone have some ideas on what might be going on here? I haven't seen something like this happen before unless the selector really doesn't exist.
The first question that comes to mind (and one you may have already answered, although I didn't see it explicitly addressed) is what is the object you are actually messaging when the crash (unknown selector exception) occurs? Does it differ at all from the successful cases? If it does differ and is not the class you expect to be messaging, then enabling zombies would be the first step in tracking down the problem.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden