So I’m debugging stuff & I get this weird-looking warning:
*** -[NSPathStore2 _rl]: unrecognized selector sent to instance 0x106fc10
Here’s the line of code which caused the error:
Needless to say, it doesn’t look promising. Single-stepping proves that the error is coming from this line, not the previous one. It also confirms that this same code has run without error a few times already.
Okay, I think, I know about t3h haxx0rz, I have otx & class-dump installed, I can find out what this is looking for. I class-dump Foundation and look for the
_rl instance method. Turns out it’s in
NSThread. Makes sense– if each thread has a runloop, NSThread should have an instance method to return that. Now, how does it get there from
[NSRunLoop currentRunLoop]? Time for some otx love.
It transpires that the answer is pretty simple. Here’s what
[NSRunLoop currentRunLoop] (presumably) looks like, based on the disassembly:
To confirm this, the very next function in the binary is
-[NSThread _rl]. Aha. However, it then raises the question— why the hemorrhaging mother-fuck is
[NSThread currentThread] returning an instance of
Another quick look via otx reveals that
+[NSThread currentThread] mostly consists of a call to
pthread_getspecific(), which, y’know, makes sense. There’s a bunch of other stuff to create the NSThread object for the main thread, or to create a new NSThread object for non-main threads which don’t already have one (hint: it calls
[NSThread new], creates a runloop, and calls
pthread_setspecific()). None of this is surprising, or indeed difficult.
The question now is: what the hell is overwriting such crucial memory as either the class table or the thread-local storage table? The ultimate answer is undoubtedly obvious to any coder worth their salt: PEBKAC. But the exact circumstances elude me right now; especially since there’s very little code in play here which hasn’t been working error-free in other projects for a while now.
Just going to be one of those days, I think…