iOS: Unrecognized selector error — but I never call that method and it doesn’t exist

Question

So this is a pretty weird one.

First of all — it doesn’t happen when running the app via Xcode. Only when the app is running standalone on the device (deployed via TestFlight or iTunes).

I use a class called RMLStarReceiptPrinter which is an interface for a portable, bluetooth receipt printer. It all works fine while running in debug mode while the device (iPhone/iPad) is connected to Xcode on dev machine.

If I run it in standalone mode, I get -[RMLStarReceiptPrinter th:]: unrecognized selector sent to instance error. But, th: method doesn’t exist in RMLStarReceiptPrinter and is never called! Another time when I ran it, it errored with the same message but selector ex:, which doesn’t exist either. But there are methods which contain th and ex substrings in their name, which tells me some kind of weird memory leak or another form of corruption makes the app send the wrong selector name. Is that possible?

Bonus: I thought that when I compile in release mode (which I do in this case), the package doesn’t contain symbol tables, so how come in the error logs there are class and selector names?

Answer 1

I can only answer the bonus part of your question, and not the actual problem.

Objective-C uses dynamic dispatch (or messaging) to invoke methods. Every method invocation goes through the following steps:

• Check the pointer is a valid object. The referenced memory will contain a header including something called an 'isa pointer'. The isa pointer is the type of class the object declares itself to be. If the memory does not reference a valid object an EXC_BAD_ACCESS error is raised.
• Using this declared class, a lookup in the Objective-C runtime is made (the Objective-C runtime is a linked library - think of it as a tiny virtual machine). If there's an entry for that method name, it will be resolved to a function pointer.
• Finally the function is invoked using the Objective-C calling convention.

The Objective-C dispatch table is assembled at runtime, and can even be modified at runtime. Its the latter feature that makes objective-C a dynamic language, despite being otherwise low level. For instance, we can do the following:

• Modify a class's isa pointer, to point to a new subclass. Add methods to this new sub-class. This is how Cocoa's powerful KVO feature works - the property setter is sub-classed on the fly to include broadcasting a message to subscribers as well as setting the property value.
• Besides modifying a single instance's behavior with isa pointer swizzling, we can modify all instances by changing the dispatch table for a class. This is useful for AOP-like behavior, for example saying "all instances of UIViewController must be security checked".

Anyway, in order to be easily programmed at runtime, messaging information is all in plain text both in debug and release mode. (Swift adds some name mangling to provide transparent namespaces).

Debugging suggestion:

Have you tried implementing those methods with a category as follows?

- (void)th {
  NSLog(@"%@", [NSThread callStackSymbols]);
}

. . this might shed some light on where things are going wrong. However, although you can add these methods via a category, and get some insight, if the class is not something your have source for, it might be necessary to work with the vendor to actually resolve the problem. (Unless you're game to try runtime patching!).