如何在 Xcode 基于 object string 属性设置条件断点?

我希望能够有调试器中断时,它达到一个特定的字符串匹配。举个例子,我可能有这样的东西:

Foo myObj = [self gimmeObj];

myObj可能有一个名为 name的属性

[myObj.name isEqualToString:@"Bar"];

如何在 Xcode 设置条件断点?

64774 次浏览

I'm not sure if this will work, but you can try setting a breakpoint at that line of code, open up the debugger console (Cmd+Shift+R), and type

condition N (int)[[myObj name] isEqualToString:@"Bar"]

Where N is replaced by the number of the breakpoint (an integer).

If you mutate myObj.name using the setter, you can add a symbolic breakpoint on -[MyObjClass setName:] either from the Debugger Console or from the Run->Manage Breakpoints->Add Symbolic Breakpoint menu in Xcode. If not (why not? you probably shouldn't be modifying the instance variable directly except in the designated initializer or dealloc) you can set a watchpoint in gdb (use the Debugger Console in Xcode once the debugger is running). This page explains how. I don't believe Xcode exposes a UI for setting watchpoints without using the Debugger Console.

You can set a conditional break point in Xcode by setting the breakpoint normally, then control-click on it and select Edit Breakpoint (choose Run -> Show -> Breakpoints).

In the breakpoint entry, there is a Condition column.

Now, there are several issues to keep in mind for the condition. Firstly, gdb does not understand dot syntax, so instead of myObj.name, you must use [myObj name] (unless name is an ivar).

Next, as with most expressions in gdb, you must tell it the type of return result, namely "BOOL". So set a condition like:

(BOOL)[[myObj name] isEqualToString:@"Bar"]

Often it is actually easier to just do this in code by temporarily adding code like:

if ( [myObj.name isEqualToString:@"Bar"] ) {
NSLog( @"here" );
}

and then setting the break point on the NSLog. Then your condition can be arbitrarily complex without having to worry about what gdb can and can't parse.

At times when working with Frameworks (debug builds) and need to put a breakpoint in certain file/location that is hard to navigate or isn't exposed publically in framework under development. One option is to write a helper class to trigger conditional breakpoints & make step-in/step-out easier.

- (void)invokeFrameworkMethod {
...
[DebugConditionalBreakPointHelper breakPointCondition:YES comment:@"from invokeFrameworkMethod."];
...
}

Header declaration in framework under development.

#import <Foundation/Foundation.h>


@interface DebugConditionalBreakPointHelper : NSObject
+ (void)breakPointCondition:(BOOL)enabled comment:(NSString *)comment;
@end

And implementation file:

#import "DebugConditionalBreakPointHelper.h"


@implementation DebugConditionalBreakPointHelper
+ (void)breakPointCondition:(BOOL)enabled comment:(NSString *)comment {
if (enabled)
{
NSLog(@"Triggerred Conditional Break Point. Comment: %@");
}
}
@end

Here is how you do using XCode lldb conditional breakpoints.

First, double click the breakpoint (or right-click edit breakpoint), you can see a dialogue popup.

Updated 2021-04-22 for Xcode 12: enter image description here

Here is what these options means:

  1. Condition: The breakpoint will only fire under this condition.
  2. Ignore: The amount of times the condition needs to meet before fire the breakpoint
  3. Action: Action that runs after the breakpoint breaks.
  4. Options: Automatically continue after evaluating actions

Here is a summary. For the above example in the image, it means that when the variable testedString is equal to "Testing", break here. If I add ignore time to 1, then it will ignore the first time when testedString is equal to "Testing" and break at the second time the condition is met.

For actions, when you press add actions, there will be a list of choices. Usually what I do is to use the Debugger Command po to print variables that I need to check and I believe that there are better ways using the actions than I do.

It seems that you have to recompile and run the app if you change the conditions at runtime