On Xcode, is it possible to set a breakpoint on an attribute value ? (stop if attr==nil for example) I know it is set to nil, but I can't find where and by whom.
Open Xcode.
Open the 'Breakpoint Navigator' (cmd+7)
In lower left, click the + button
Select 'Add Symbolic Breakpoint..'
In 'Symbol' add: [YourObject setYourAttribute:]
In 'Condition' add: yourAttribute == nil
This will get called anytime yourAttribute on YourObject is set to nil. You can then look at the trace to see what sequence of events led to that call. I'm pretty sure that's what you're asking.
If you don't use a setter to access the variable in question, you'll have to drop down to using LLDB (Xcode's debugger) directly to do what you want.
Set a normal breakpoint in a context where the variable you're interested in is in scope, and before it has been written by your mystery writer. Then, access the debugger pane, and enter the following command:
watchpoint set variable -w write <variable-name>
where <variable-name> is the name of the variable you'd like to watch – perhaps attr in this case. This will set a hardware watchpoint which will trigger when your variable is changed.
If you want to explore LLDB a little more, try help commands in the debugger. For example, you could type:
help watchpoint set variable
to see the help entry for the command I've recommended.
EDIT: Apparently you can also set such watchpoints from the Xcode GUI. Who knew?
1) Set breakpoint in the method
2) Right click on the breakpoint, and select "Edit Breakpoint"
3) Add Condition attr == nil
4) Click somewhere in Xcode.
You are ready to go, breakpoint will stop whenever attr == nil
Related
I've been playing around with keyboard shortcuts in Pharo 7.0. I wanted to modify the binding for #jumpToNextKeywordOfIt in the Smalltalk editor and so I got the following change in the definition of buildShortcutsOn method:
(aBuilder shortcut: #jumpToNextKeywordOfIt)
category: RubSmalltalkEditor name
default: $y meta shift
do: [ :target | target editor jumpToNextKeywordOfIt: true ]
description: 'Jump to next keyword'.
My first thought was that just saving this definition should immediately take effect, but it was not the case. Then I thought, perhaps since this is part of a method definition, then calling this method on the editor class would do the trick. Now, the method takes an argument aBuilder and I don't really know what that is. So two questions arise:
Is this the proper way to apply keybinding changes to a running editor?
What is aBuilder in this context and how does one get it?
Let me give you some hints on how to find the solution (as this might be more valuable than giving the solution at once)
The problem is what's aBuilder right? Well, from the expression
(aBuilder shortcut: #jumpToNextKeywordOfIt)
we deduce that aBuilder is someone that responds to #shortcut:. Cmd+m and you will get 9 implementors of #shortcut:. One of them, KMBuilder has an interesting name. Moreover, its implementation of shortcut: is
shortcut: aKeymapName
^KMKeymapBuilder
for: aKeymapName
platform: platform
meaning that it will answer with an instance of KMKeymapBuilder. Browse this class and verify that it understands the next message from your expression:
category: RubSmalltalkEditor name
default: $y meta shift
do: [ :target | target editor jumpToNextKeywordOfIt: true ]
description: 'Jump to next keyword'.
It does! So this must be it! To check this, we still need an instance of KMBuilder. Browse the class, go to the class side and find the unary message #keymap.
This means that we can obtain aBuilder by evaluating
KMBuilder keymap
I love unary messages. Specially when they are on the class side!
Now go to the implementor of the method you already tweaked #buildShortcutsOn:. It is implemented in the class side and we can now evaluate:
RubTextEditor buildShortcutsOn: KMBuilder keymap
To make sure that it works, go now to the desired handler #jumpToNextKeywordOfIt: and insert a halt in it. This is in the same class, instance side.
Now lets press Cmd+Shift+y and see if we get the halt... Bingo! I mean, Halt!
I have a question about debugging mode in JetBrains IDEs (PyCharm, WebStorm, IntelliJ ..). Let's say I have a line in the code that looks like this:
....func1()...func2()...func3()...
Several functinos are called in the same line, and none of them is assigned to a variable. Now, I want to know what is the return value of each of these functions. I know the feature Evaluate Expression, but I don't want to use it, since it may invoke these functions again.
Do you know any way to find the return values of a function without assigning its value to a variable and checking its value in debugger?
As of PyCharm 2016.2, you can show function return values; to do so, you need to:
Click on the Settings gear icon in the left-hand toolbar of the Debug panel
Ensure that Show Return Values is checked
Then when a Return Value is present, you will see it listed under Return Values at the top of the Variables section of the Debug panel (and that information is retained while still in the calling function)
I don't think that this is possible right now but you could set breakpoints inside the functions itself.
Additionally you could add a "Disable until selected breakpoint is hit" + "Disable again" and join them with a breakpoint above the line you posted to make sure they are only called from this line.
Or simply refactor your code:
foobar.huey()
.dewey()
.louie();
and set line breakpoints as usual.
I was looking also for this, and I can link you an answer I found, extending the answer of David Fraser: in IntelliJ, someone replied with screenshots to a similar question in this same site:
java - Can I find out the return value before returning while debugging in Intellij
Remember to put a breakpoint inside the function and step out :)
As said there (although it includes screenshots, much better than this) by the user Birchlabs:
On IntelliJ IDEA 2016.3: it's hidden inside the cog button of the
debug panel. Ensure Show Method Return Values is checked.
IntelliJ IDEA 2016.3 "Show Method Return Values"
Use the debugger to break somewhere inside the function whose return
value you'd like to see.
step into function
Step out of the function (or step over until you escape):
step out
Observe that the return value appears in your variables:
observe the return value
My end goal is to modify an Objective-C program's symfile in LLDB. I want to augment the method names so a new, unique name can be used to reference an existing method in the debug symbol file.
For example, if there is a method named -[Foo bar], I can of course break on this method using (lldb) b -[Foo bar], however, I want to create an "alias" for this method named -[Foo baz], so when I execute the following in lldb:
(lldb) b -[Foo baz]
A breakpoint will get set on the address at:
method_getImplementation(class_getInstanceMethod([Foo class], #selector(bar)))
My current method of solving this is to use the dsymutil function to dump the symfile:
dsymutil /path/to/executable -o dump.dYSM
From there, I can use the dwarfdump command to prettify the output into something I can actually edit.
dwarfdump dump.dYSM/Contents/Resources/DWARF/ExecName
Now I can easily edit the AT_name property which contains -[Foo bar]
However, I don't know how to regenerate the dYSM after I have the debug info in this "prettify" format.
Provided I can regenerate the edited dYSM, I am hoping to stick it back into LLDB using either:
(lldb) target modules add or (lldb) target symbol add
So my questions are:
Is there a better way to go about this? Note that I do not have the source nor the object files to regenerate a new dYSM.
Is there a Terminal command that can patch up my edited dwarfdump for me into a LLDB readable debug symbol file?
Cheers!
I'm not entirely clear what you are trying to achieve. It sounded at first like you were trying to break on the dynamically determined implementation of some class/selector pair, in which case you can just do:
(lldb) break set -a `(void *) method_getImplementation((void *)class_getInstanceMethod([Foo class], #selector(bar)))`
Note, you'll have to do this after you've run your program and hit a breakpoint, but then you won't know the specific implementation that's going to get called until you run anyway, so this isn't much of a restriction.
But just munging the name in the DWARF wouldn't have actually achieved this effect. So maybe if you say a little more about your actual aims we can be of more help.
As to question 2, there are no tools to edit dSYM DWARF content after the fact. That's not something there's been much call for.
When calling a block, I can print its address by doing "po block" in the debug console. What can I do to print the address of a block I am currently in (i.e. when the debugger hits a breakpoint within the block)?
Note that the block can be anonymous block.
I haven't tested this, but you can get the address of a label using the && GNU extension, so you might be able to do something like this in any block, named or otherwise:
block_start:
// Some code
NSLog(#"Block at 0x%p", &&block_start);
Typing frame variable lists all the parameters and local variables in the frame along with their values, which when executing a block, includes the pointer to the block object itself as an entry called .block_descriptor. The value of the pointer (the address of the block object it points to) is printed next to it. You can then do po on that address if you like.
I haven't found a way to use this .block_descriptor thing by itself in the debugger (e.g. it is not accepted as a valid expression).
Ok, so say you were getting an error when compiling such as..
Retain'ed block property does not copy the block - use copy attribute instead
because of...
-Wobjc-noncopy-retain-block-property
to which you could fix the problem, or possibly add a flag such as
-Wno-objc-noncopy-retain-block-property
But let's further suppose you liked to use "Configuration" (.xcconfig) files, and you thought, "OK, since I can use...
CLANG_WARN_DEPRECATED_OBJC_IMPLEMENTATIONS = NO
maybe I'll try.."
CLANG_WARN_OBJC_NONCOPY_RETAIN_BLOCK_PROPERTY = NO
Only to discover this does NOT work.
So the question retains, umm remains... What DOES work?
Xcode allows you to copy entries from the Build Settings pane using ⌘-C; the result when pasting is the text that corresponds to that setting for use in an .xcconfig file.
When I entered -Wno-objc-noncopy-retain-block-property into the "Other Warning Flags" row, and copy-pasted that into a new .xcconfig file, I ended up with this:
//:configuration = Debug
WARNING_CFLAGS = -Wno-objc-noncopy-retain-block-property
//:configuration = Release
WARNING_CFLAGS = -Wno-objc-noncopy-retain-block-property
and that does indeed seem to supress the warning about a retain Block property.