Instance not responding to selector

I have a set of plugins which I load via a custom framework. The plugins load and behave correctly in the UI.

I have a set of corresponding "rule" objects, one for each class of plugin. A plugin may load data from a rule, and a rule may load data from a plugin: -[RSRule loadFromPlugin:(RSPlugin*)plugin] or -[RSPlugin loadFromRule:(RSRule*)rule]. I have moved away from using categories to do this and the classes implement these methods internally. The header files list the methods correctly.

However, after a clean and build, attempting to invoke any of these -[loadFrom..:] methods causes a crash reporting "unrecognized selector".

Any advice on how I could narrow down what is causing this? I have tried using repondsToSelector: but this doesn't do anything but confirm what the error message states, that the selector is not recognized.

> Any advice on how I could narrow down what is causing this? I have tried using repondsToSelector: but this doesn't do anything but confirm what the error message states, that the selector is not recognized.

More than that, it states that the selector is not recognized _by RSReactionRule_. Are you sending that message to an RSReactionRule? If you don't think you are, set a breakpoint (presumably somewhere in -addRuleToStore:), and examine the recipient of that message; does the debugger think it's an RSReactionRule?

There are two main reasons an object won't recognize a selector.

- You blundered and wrote code that sent the selector to the wrong object. This is fairly obvious, and the compiler usually urges you not to do it anyway.

- You sent the message via an object pointer that _used_ to point to a legitimate receiver for the selector, but that object had been deallocated, and the address recycled for another object (an RSReactionRule) that doesn't implement it. In other words, the object got (over)released out from under you. Audit your memory management (better, adopt ARC). The Allocations instrument, set to record reference counts and enabling zombie detection, should help you track this down.

Or, maybe there's something esoteric going on with your plugin loading. But I'd look at these two possibilities first.

I should have stated that I am building against 10.8, and using ARC, and using Xcode 4.4DP6. I don't believe the issues I'm facing are all that esoteric so I don't think the version of XC is likely to effect this situation.

On 2012-07-10, at 10:02 PM, Fritz Anderson <fritza...> wrote:

> On 10 Jul 2012, at 11:03 PM, Erik Stainsby wrote:
> >> Any advice on how I could narrow down what is causing this? I have tried using repondsToSelector: but this doesn't do anything but confirm what the error message states, that the selector is not recognized.>
> More than that, it states that the selector is not recognized _by RSReactionRule_. Are you sending that message to an RSReactionRule? If you don't think you are, set a breakpoint (presumably somewhere in -addRuleToStore:), and examine the recipient of that message; does the debugger think it's an RSReactionRule?

The object which is failing to respond is of the correct class: RSReactionRule in this case, generally an RSTrixieRule subclass. The object is newly allocated and initialized. It has not been sent any other messages at the point of failure.

> There are two main reasons an object won't recognize a selector.
>
> - You blundered and wrote code that sent the selector to the wrong object. This is fairly obvious, and the compiler usually urges you not to do it anyway.

I believe I have sent it to the correct object.

> - You sent the message via an object pointer that _used_ to point to a legitimate receiver for the selector, but that object had been deallocated, and the address recycled for another object (an RSReactionRule) that doesn't implement it. In other words, the object got (over)released out from under you. Audit your memory management (better, adopt ARC). The Allocations instrument, set to record reference counts and enabling zombie detection, should help you track this down.

I am using ARC and have no reason to believe that ARC has reclaimed my newly instantiated object. Calling on it for a description in NSLog statements results in a coherent description being logged. So something of the correct class is at the other end of the pointer being referenced.

> Or, maybe there's something esoteric going on with your plugin loading. But I'd look at these two possibilities first.

The plugin loading seems straightforward. I create a loader from the framework, iterate over the plugins found in my apps' Plugins folder, instantiate and store the plugins in an array. When they have been loaded, I set the loader nil. Each plugin has a UI component which loads in its correct place and exhibits all the behaviour I expect it to. It just doesn't;t seem to me that there is room for subtle errors here. I'd be happy to post loader code if that seems likely to anyone.

> I should have stated that I am building against 10.8, and using ARC, and using Xcode 4.4DP6

Then I can't help. Aside from the fact that my problem-solving technique* would require me to sit down for an hour or two and grope around your project by hand, those products are still under nondisclosure.

* (Others, with direct experience and better imaginations, may be more effective.)

I know it's hairsplitting, given that what's currently on the servers is likely to be identical to what will be public in a week or two, but that's where the line is drawn.

> On 11 Jul 2012, at 1:33 AM, Erik Stainsby wrote:
> >> I should have stated that I am building against 10.8, and using ARC, and using Xcode 4.4DP6>
> Then I can't help. Aside from the fact that my problem-solving technique* would require me to sit down for an hour or two and grope around your project by hand, those products are still under nondisclosure.
>
> * (Others, with direct experience and better imaginations, may be more effective.)
>
> I know it's hairsplitting, given that what's currently on the servers is likely to be identical to what will be public in a week or two, but that's where the line is drawn.
>
> — F

The build results behave exactly the same when I switch the target to 10.7