When Is a Constraint Error Breakpoint Hit?

I've been experimenting with Xcode's Constraint Error breakpoint, but it's not being hit when the project contains Auto Layout issues. The outpout in Xcode's console clearly indicates the user interface has conficting constraints and the debugger suggests to add a symbolic breakpoint, but the Constraint Error breakpoint itself isn't being hit. Is this a known issue or am I overlooking something?

Answered by DTS Engineer in 299281022

You can see what these ‘magic’ breakpoints do under the covers by using LLDB’s

breakpoint list
command. For example, after setting a Constraint Error breakpoint I see this:
(lldb) br list
Current breakpoints:
1: name = 'LAYOUT_CONSTRAINTS_NOT_SATISFIABLE', locations = 0 (pending)

Note that the

locations
value is 0, indicating that the breakpoint hasn’t been resolved to any actual locations. Clearly it’s not going to be effective in that case.

The above was on iOS (11, in the simulator). When I run the same test on macOS (10.13) I see this:

(lldb) br list 
Current breakpoints:
1: name = 'LAYOUT_CONSTRAINTS_NOT_SATISFIABLE', locations = 1, resolved = 1, hit count = 0

  1.1: where = AppKit`LAYOUT_CONSTRAINTS_NOT_SATISFIABLE, address = 0x00007fff28d130b1, resolved, hit count = 0

It seems like this is an AppKit-specific feature. Are you testing this on iOS? If so, that explains why you’re not getting any hits.

You wrote:

The outpout in Xcode's console clearly indicates the user interface has conficting constraints and the debugger suggests to add a symbolic breakpoint …

What exactly does it say?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"
Accepted Answer

You can see what these ‘magic’ breakpoints do under the covers by using LLDB’s

breakpoint list
command. For example, after setting a Constraint Error breakpoint I see this:
(lldb) br list
Current breakpoints:
1: name = 'LAYOUT_CONSTRAINTS_NOT_SATISFIABLE', locations = 0 (pending)

Note that the

locations
value is 0, indicating that the breakpoint hasn’t been resolved to any actual locations. Clearly it’s not going to be effective in that case.

The above was on iOS (11, in the simulator). When I run the same test on macOS (10.13) I see this:

(lldb) br list 
Current breakpoints:
1: name = 'LAYOUT_CONSTRAINTS_NOT_SATISFIABLE', locations = 1, resolved = 1, hit count = 0

  1.1: where = AppKit`LAYOUT_CONSTRAINTS_NOT_SATISFIABLE, address = 0x00007fff28d130b1, resolved, hit count = 0

It seems like this is an AppKit-specific feature. Are you testing this on iOS? If so, that explains why you’re not getting any hits.

You wrote:

The outpout in Xcode's console clearly indicates the user interface has conficting constraints and the debugger suggests to add a symbolic breakpoint …

What exactly does it say?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you for your response, Quinn. Your answers are always lifesavers. This clears everything up. I have to admit that it's confusing and I'm wondering if this is a bug. Your answer once again shows how useful it can be to learn more about the LLDB debugger.


To answer your question, this is the output I'm seeing in Xcode's console. I can probably accomplish the same by adding a symbolic breakpoint as Xcode suggests.


2018-03-16 07:54:00.064979+0100 Breakpoints[73295:2788883] [LayoutConstraints] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(
    "<NSLayoutConstraint:0x6180000990f0 UILabel:0x7f9486403a70'Label'.width == 100   (active)>",
    "<NSLayoutConstraint:0x618000099190 UILabel:0x7f9486403a70'Label'.width == 200   (active)>"
)


Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x618000099190 UILabel:0x7f9486403a70'Label'.width == 200   (active)>


Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
2018-03-16 07:54:00.065366+0100 Breakpoints[73295:2788883] [LayoutConstraints] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(
    "<NSLayoutConstraint:0x6180000990f0 UILabel:0x7f9486403a70'Label'.width == 100   (active)>",
    "<NSLayoutConstraint:0x61c000097b10 UILabel:0x7f9486403a70'Label'.width == 200   (active)>"
)


Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x61c000097b10 UILabel:0x7f9486403a70'Label'.width == 200   (active)>


Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.


Thanks again for your time, Quinn. I appreciate it.

Hi. it's great to inspect the stats of a breakpoint using: "br list", however this does not answer the original question of: Why our constraint breakpoints are not firing in the first place? I use "br list" and it shows a "hit count" of 0 on all the constraint breakpoints. I still don't know why they don't get hit. I have constraint errors such as:


2019-09-11 13:22:10.218401-0400 My App [111:222] [LayoutConstraints] Unable to simultaneously satisfy constraints.

Probably at least one of the constraints in the following list is one you don't want.

Try this:

(1) look at each constraint and try to figure out which you don't expect;

(2) find the code that added the unwanted constraint or constraints and fix it.

(

"<NSLayoutConstraint:0x7fbf1f6ac620 UITableView:0x7fbf1a27f200.height == 171 (active)>",

"<NSLayoutConstraint:0x7fbf1f5fa4e0 UIView:0x7fbf1f5f8090.height == 214 (active)>",

"<NSLayoutConstraint:0x7fbf1f5fa620 V:|-(>=40)-[UITableView:0x7fbf1a27f200] (active, names: '|':UIView:0x7fbf1f5f8090 )>",

"<NSLayoutConstraint:0x7fbf1f5faaa0 V:[UITableView:0x7fbf1a27f200]-(25)-| (active, names: '|':UIView:0x7fbf1f5f8090 )>"

)


The "Constraint Error" type breakpoint does not fire.


Here are my breakpoints:


Current breakpoints, as output by "br list":


1: name = 'LAYOUT_CONSTRAINTS_NOT_SATISFIABLE', locations = 0 (pending)


2: name = 'UICollectionViewFlowLayoutBreakForInvalidSizes', locations = 1, resolved = 1, hit count = 0


2.1: where = UIKitCore`UICollectionViewFlowLayoutBreakForInvalidSizes, address = 0x0000000113bacec4, resolved, hit count = 0


3: names = {'-[UIView(UIConstraintBasedLayout) _viewHierarchyUnpreparedForConstraint:]', '-[UIView(UIConstraintBasedLayout) _viewHierarchyUnpreparedForConstraint:]'}, locations = 1, resolved = 1, hit count = 0


3.1: where = UIKitCore`-[UIView(UIConstraintBasedLayout) _viewHierarchyUnpreparedForConstraint:], address = 0x00000001146dfea2, resolved, hit count = 0



Any suggestions?


Thanks in advance.

Alex

OK, adding a Symbolic Breakpoint on UIViewAlertForUnsatisfiableConstraints works great and pauses on the stack trace of the constraint causing the problem. I just didn't have any luck using the standard "Constraint Breakpoint" type in XCode. I'm on version 10.3.


Thanks,

Alex

When Is a Constraint Error Breakpoint Hit?
 
 
Q