Break on `unrecognized selector sent to instance` during debuging session

Question

While debugging a view hiearchy with expression -o -- (NSString *)[[UIWindow keyWindow] recursiveDescription] I've received a -[UILabel length]: unrecognized selector sent to instance 0xd4ebe50. I would like to use LLDB to debug the problem and get a stack trace if the debugger gets an unrecognized selector.

I've tried

setting an exception breakpoint in Xcode
setting a breakpoint w/ breakpoint set --selector length and
setting a breakpoint w/ breakpoint set --selector -[UILabel length]

Setting a breakpoint manually leads to the warning WARNING: Unable to resolve breakpoint to any actual locations. The breakpoints are not triggered during debugging.

Is it possible to stop on unrecognized selector and get a stack trace?

Won't that cause a crash anyway, from which you can view the stack (`bt` command)? — trojanfoe, Jul 01 '13 at 14:58
Add an exception breakpoint. In breakpoint window press `+` at the bottom and select "Add Exception Breakpoint". Or see [this](http://stackoverflow.com/a/12268397/581994). — Hot Licks, Jul 01 '13 at 16:48
@chaiguy If you're still interested, I've added an answer to my question. — mkalmes, Oct 17 '13 at 19:17

score 2 · Answer 1 · answered Jul 02 '13 at 00:52

2

In xCode you can set breakpoints to all Objective-C unhanded exceptions. To do that, in the Breakpoint Navigator, press the + symbol in the bottom-left corner of the navigator, and select "Add Exception Breakpoint":

enter image description here

You will see an "All exceptions" entry. Right click that, select Edit Breakpoint and configure it as follows:

enter image description here

Then, when your app crashes, the execution will break in the conflict code, showing the stack trace and all the information you need.

Hope it helps!

answered Jul 02 '13 at 00:52

lucaslt89

2,431
1
20
30

1

This was my first step. Didn't worked because lldb reverts to previous app state before an exception gets handled. – mkalmes Jul 02 '13 at 07:39
Had done this before but then Xcode forgot my settings and it was gone again. Thanks! One of these super obscure Xcode things I'll never remember. Why wouldn't it break on exceptions by default? – n13 Dec 11 '14 at 08:11

score 2 · Answer 2 · answered Jul 12 '20 at 19:51

Underlying the Xcode Objective-C exception breakpoint in @lucaslt89's answer is an lldb breakpoint which is simply:

breakpoint set --name objc_exception_throw

For an unrecognized selector error you can also break on -[NSObject(NSObject) doesNotRecognizeSelector:].

score 1 · Answer 3 · edited May 23 '17 at 12:25

breakpoint set --selector didn't work correctly in Xcode 4.6 without a dSYM for the relevant library (UIKit in this case).

I would expect breakpoint set -n "-[UILabel length]" to work though. Or you can add a Symbolic breakpoint in Xcode. Debug > Breakpoints > Create Symbolic Breakpoint and you should be able to enter -[UILabel length].

Keep in mind that the shortest unique command is always valid in lldb, so br s -S length would be another way to write breakpoint set --selector length.

A similar question is over in unrecognized selector sent to instance where one recommendation is to po 0xd4ebe50.

score 1 · Answer 4 · answered Oct 17 '13 at 19:15

Is it possible to stop on unrecognized selector and get a stack trace?

To stop lldb from rewinding the app state call expression with --unwind-on-error false (short: -u false). lldb will not clean up the state, if this option was used.

However, this didn't helped me to debug where in the view hierarchy the label was located. lldb told me from the very beginning, that the label could be found at address 0xd4ebe50. The output of po [0xd4ebe50 text] gave me a clue where to investigate. I've added a green background to the label for further assistance. The culprit was a label named description which caused the problem in regards to -recursiveDescription.

Break on `unrecognized selector sent to instance` during debuging session

4 Answers4