UIResponder doesNotRecognizeSelector

Question

I'm getting lots of crashes with the following backtrace and I can't find the cause for it.

According to Apple -[NSObject(NSObject) doesNotRecognizeSelector:] occurs when a new object is allocated in the memory previously occupied by the deallocated object.

Note: Messaging a previously deallocated object may raise an NSInvalidArgumentException instead of crashing the program with a memory access violation. This occurs when a new object is allocated in the memory previously occupied by the deallocated object. If your application is crashing due to an uncaught NSInvalidArgumentException (look for -[NSObject(NSObject) doesNotRecognizeSelector:] in the exception backtrace), consider profiling your application with the Zombies instrument to eliminate the possibility that improper memory management is the cause.

https://developer.apple.com/library/archive/technotes/tn2151/_index.html

But what's up with the rest of the backtrace, especially -[UIUndoGestureInteraction didMoveToView:] thing?

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Triggered by Thread:  0

Last Exception Backtrace:
0   CoreFoundation                  0x1ae45498c __exceptionPreprocess + 220 (NSException.m:199)
1   libobjc.A.dylib                 0x1ae17d0a4 objc_exception_throw + 56 (objc-exception.mm:565)
2   CoreFoundation                  0x1ae35843c -[NSObject(NSObject) doesNotRecognizeSelector:] + 140 (NSObject.m:144)
3   UIKitCore                       0x1b24902a8 -[UIResponder doesNotRecognizeSelector:] + 296 (UIResponder.m:659)
4   CoreFoundation                  0x1ae458e08 ___forwarding___ + 1324 (NSForwarding.m:3325)
5   CoreFoundation                  0x1ae45abec _CF_forwarding_prep_0 + 92
6   UIKitCore                       0x1b2353040 -[UIUndoGestureInteraction didMoveToView:] + 108 (UIUndoGestureInteraction.m:725)
7   UIKitCore                       0x1b28eb3c4 _setInteractionView + 84 (UIView.m:16421)
8   UIKitCore                       0x1b28eb2a0 -[UIView(Dragging) addInteraction:] + 268 (UIView.m:16450)
9   UIKitCore                       0x1b26cd2b8 -[UIEditingOverlayViewController _addInteractions] + 260 (UIEditingOverlayViewController.m:79)
10  UIKitCore                       0x1b1e5b2ec -[UIViewController _setViewAppearState:isAnimating:] + 832 (UIViewController.m:4695)
11  UIKitCore                       0x1b1e5b6fc __52-[UIViewController _setViewAppearState:isAnimating:]_block_invoke + 268 (UIViewController.m:4758)
12  CoreFoundation                  0x1ae42773c __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 16 (NSArrayHelpers.m:9)
13  CoreFoundation                  0x1ae32b86c -[__NSArrayI enumerateObjectsWithOptions:usingBlock:] + 152 (NSArrayI.m:108)
14  UIKitCore                       0x1b1e5b49c -[UIViewController _setViewAppearState:isAnimating:] + 1264 (UIViewController.m:4736)
15  UIKitCore                       0x1b1e5d530 __64-[UIViewController viewDidMoveToWindow:shouldAppearOrDisappear:]_block_invoke + 44 (UIViewController.m:5272)
16  UIKitCore                       0x1b1e5c32c -[UIViewController _executeAfterAppearanceBlock] + 88 (UIViewController.m:5050)
17  UIKitCore                       0x1b246bca4 _runAfterCACommitDeferredBlocks + 584 (UIApplication.m:3027)
18  UIKitCore                       0x1b245b7c0 _cleanUpAfterCAFlushAndRunDeferredBlocks + 232 (UIApplication.m:2986)
19  UIKitCore                       0x1b248b594 _afterCACommitHandler + 76 (UIApplication.m:3048)
20  CoreFoundation                  0x1ae3d1c48 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32 (CFRunLoop.c:1758)
21  CoreFoundation                  0x1ae3ccb34 __CFRunLoopDoObservers + 416 (CFRunLoop.c:1868)
22  CoreFoundation                  0x1ae3cd100 __CFRunLoopRun + 1308 (CFRunLoop.c:2910)
23  CoreFoundation                  0x1ae3cc8bc CFRunLoopRunSpecific + 464 (CFRunLoop.c:3192)
24  GraphicsServices                0x1b8238328 GSEventRunModal + 104 (GSEvent.c:2246)
25  UIKitCore                       0x1b24626d4 UIApplicationMain + 1936 (UIApplication.m:4753)
26  JustConnect                     0x10425ca60 main + 68 (APIInfoUser.swift:7)
27  libdyld.dylib                   0x1ae257460 start + 4

Answer 1

Here's the response from an Apple Developer & Technical Support:

The key thing to notice here is that frames 0 through 5 of this backtrace are just boilerplate associated with an unrecognised selector. That is, frame 6 has called a method on an object, the object didn’t recognise that selector so it entered the Objective-C runtime forwarding infrastructure (frames 5 through 4). That landed in UIResponder (frame 3) because UIResponder support some sort of generic message forwarding. That message forwarding failed, so UIResponder called super (frame 2), which then threw the exception.

So the real question is, what’s going on in frame 6. To learn more about this, you can disassemble the code (-:

(lldb) disas -n '-[UIUndoGestureInteraction didMoveToView:]'  
UIKitCore`-[UIUndoGestureInteraction didMoveToView:]:  
    0x1bbe92fd4 <+0>:   stp    x22, x21, [sp, #-0x30]!  
    0x1bbe92fd8 <+4>:   stp    x20, x19, [sp, #0x10]  
    0x1bbe92fdc <+8>:   stp    x29, x30, [sp, #0x20]  
    0x1bbe92fe0 <+12>:  add    x29, sp, #0x20    ; =0x20   
    0x1bbe92fe4 <+16>:  mov    x21, x2  
    0x1bbe92fe8 <+20>:  mov    x19, x0  
    0x1bbe92fec <+24>:  add    x20, x0, #0x10    ; =0x10   
    0x1bbe92ff0 <+28>:  mov    x0, x20  
    0x1bbe92ff4 <+32>:  mov    x1, x2  
    0x1bbe92ff8 <+36>:  bl     0x1b7cd71d8       ; objc_storeWeak  
    0x1bbe92ffc <+40>:  cbz    x21, 0x1bbe930a8  ; <+212>  
    0x1bbe93000 <+44>:  adrp   x8, 208464  
    0x1bbe93004 <+48>:  add    x1, x8, #0x7b1    ; =0x7b1   
    0x1bbe93008 <+52>:  mov    x0, x19  
    0x1bbe9300c <+56>:  bl     0x1b7cb9180       ; objc_msgSend  
    0x1bbe93010 <+60>:  mov    x0, x20  
    0x1bbe93014 <+64>:  bl     0x1b7cd7a80       ; objc_loadWeakRetained  
    0x1bbe93018 <+68>:  mov    x20, x0  
    0x1bbe9301c <+72>:  adrp   x8, 208304  
    0x1bbe93020 <+76>:  add    x1, x8, #0xc04    ; =0xc04   
    0x1bbe93024 <+80>:  bl     0x1b7cb9180       ; objc_msgSend  
    0x1bbe93028 <+84>:  mov    x29, x29  
    0x1bbe9302c <+88>:  bl     0x1b7cd8864       ; objc_retainAutoreleasedReturnValue  
    0x1bbe93030 <+92>:  mov    x21, x0  
    0x1bbe93034 <+96>:  adrp   x8, 208502  
    0x1bbe93038 <+100>: add    x1, x8, #0xbb7    ; =0xbb7   
    0x1bbe9303c <+104>: bl     0x1b7cb9180       ; objc_msgSend  
    0x1bbe93040 <+108>: stp    d0, d1, [x19, #0x100]  

There’s a bunch of things you can learn here. First, frame 6 in the backtrace has an offset of +108, so that actual call that failed is at +104. An objc_msgSend, has two standard parameters, the target object and the selector. On 64-bit Arm these map to x0 and x1, respectively.

Let’s look at the selector first. This is constructed by the two instructions at +96 and +100. Those two instructions form a PC-relative address. The adrp instruction (‘add relative to page’) takes the current PC (0x1bbe93034), clears the bottom 12 bits (0x1bbe93000, remember that the historical page size is 4096 [1]), and then takes the literal, shifts it left by 12 bits (208502 << 12), and then adds it in. The add instruction is much simpler. It takes the result from the previous calculation and adds 0xbb7 (note the switch from decimal to hex!).

If you run this calculation in the debugger you’ll see this:

(lldb) p (char*)( 0x1bbe93000+(208502<<12)+0xbb7)  
(char *) $1 = 0x00000001eed09bb7 "actualSceneBounds" 

So the selector is actualSceneBounds. Cool.

Now let’s look at the object. At the time of the call (+104) this is expected to be in x0. At +92 we see it copy x0 to x21, but this is just a distraction. Actually x0 is the function result from objc_retainAutoreleasedReturnValue at +88. That function takes and returns an object, so x0 is the value returned by the message send at +80. Doing the same relative page trick we did earlier, we see that the selector for that call is -window. But what object is that being called on?

Working that out is… well… kinda complex because of the objc_storeWeak / objc_loadWeakRetained dance. I believe it boils down to the value passed into this method via x2, that is, the third parameter. Based on the method name, this is clearly a view (remember that, for Objective-C methods, the first two parameters, x0 and x1, hold the target and the selector, so x2 holds the first actual parameter).

So, in summary:

• It seems that this method has a view parameter.

• It’s requested window.window.screenBounds.

• The last property access has failed because the thing that’s meant to be a window doesn’t implement the -screenBounds getter.

I don’t know enough about UIKit to explain the background to that. I have a couple of suggestions here:

1. Run the Standard Memory Debugging Tools, and specifically Zombies, to see if they turn up anything useful. Make sure to exercise the undo gesture, based on the class name of the method we pulled apart.

2. If that doesn’t pan out, bounce over to App Frameworks > Cocoa Touch to see if anyone there has any suggestions.

Share and Enjoy

—

[1] On 64-bit Arm the actual page size is typically 64 KiB, but the adrp instruction uses the historical page size of 4096 because it matches the maximum literal size in the add instruction.

https://forums.developer.apple.com/message/389467