I've noticed an unexpected behavior in an object used in this really complicate framework.
What I want is that the debugger stops (like with breakpoints) every time that the object appears in an instruction, without manually add breakpoints in all the instruction where it is used/appears.
Can I do something like this in IntelliJ?
Field Breakpoint is what you are looking for.
Read breakpoint type overview to get an overview of the different breakpoint types.
Furthermore, it is possible to put a condition on a breakpoint - read configure breakpoints.
Related
Is there a way to somehow add breakpoints to all lines where some code is called outcluding method definitions since it takes a long time to debug it.
I got a messy code where I need to add some new functionalities but I just can't find them by following the code. It's like something is initialized on the start but I can't find where or what.
You can use the plugin "Simple Toogle All Method Breakpoint", with a right click on the project folder you can toggle Breakpoints at all methods of your project.
When running a program I need to see every time a certain button is disabled and step through the code at that point.
If I set a breakpoint with a condition
(ex: only hit when button1.enabled=false) it will only hit in that specific place.
Is it possible to set a breakpoint on the entire program so that i can see when a condition changes across many forms and locations?
You can't set one breakpoint and have it apply to every line of the file, but you can set a breakpoint on the setter of Enabled and then filter it to a specific filter condition. That would give you the desired result. (Note, you might need to turn off "Just my code", see this question for more info)
Set a breakpoint using the "New Breakpoint At Function" as described here, though in Visual Studio 2013, I seem to need to use a slightly different notation:
Then set the breakpoint to funtion:
System.Windows.Forms.Control.Enabled
in C# or for VB.NET:
System.Windows.Forms.Control.set_Enabled(bool)
(You seem to need to use the class that actually defines the property, which in case of the Button class' Enabled property, is the Control class the Button inherits from.
Ignore the warning about it not being able to find the function (it does that for properties somehow), or uncheck the Intellisense lookup.
Now look up the breakpoint in the Breakpoints list and customize the condition so it breaks on the right button
Use the Name property (or any other filter that makes the breakpoint unique) to trigger when you need it to:
When it breaks, it will break in the sources of Control (if you have Framework Source Stepping enabled), which may be confusing. Use the Stack Trace window to find the location where the method was invoked exactly.
Another way of setting the breakpoint is through the Stacktrace window. Set a breakpoint on any line that has your property of interest on it. Launch the debugger and make it break on that line, now use "Step into Specific" to step into the property that you want to break on.
Use the "Stack" window to generate the breakpoint for you:
Since in your case you're looking to break on a function from the Microsoft .NET framework, there is another way. Enabled Framework Source Stepping.
Open the Visual Studio Debugger options and enable "Framework Source Stepping" and disable "Just My Code".
Then enable the Microsoft Symbol Servers in as instructed. Now load up your application under the debugger and wait for the symbol files to be downloaded.
set a break point anywhere in your code that is somehow related to System.Windows.Forms (The constructor of your MainForm for example) and rightclick any function from the "System.Windows.Forms" assembly to load the symbols for that assembly. This will allow you to step into the "Enabled" property and set a break point there.
A full tutorial can be found here:
http://blogs.msdn.com/b/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx
Some part of a big code base is printing out weird NSLog statements, and I'm trying to detect where it's coming from. Is there a way to put 1 breakpoint at the start of every NSLog call so I can see where it's being called from, rather than manually have to put breakpoints on all places that call NSLog?
In Xcode 6:
Step 1:
On the Navigator on the left, go to Breakpoint Navigator (command ⌘ + 7):
Step 2:
Click the + button on the bottom left (Add a new breakpoint),
then choose Add Symbolic Breakpoint...:
Step 3:
In Symbol, type NSLog.
Alternatively, you can do the same thing in Debug → Breakpoints → Create Symbolic Breakpoint.
Fo Xcode 5, see this.
If you want to break on a certain log message you can use:
This example will break on every log containing the word "Warning".
Update:
On newer devices use $x0.
Simulator and older use $r0.
$arg0 should do for all cases.
In the breakpoint navigator (command+6) add (on the bottom, there is a Plus symbol) a symbolic breakpoint and use NSLog as symbol.
According to this you can set that kind of breakpoint by doing so in the lldb console:
breakpoint set --name NSLog
One way to do this using Xcode could be to put a breakpoint in the main function or on you AppDelegate applicationDidFinishLaunchin (read: as soon as possible).
Then, you run your app, and when it pauses on said breakpoint, you have access to the lldb console: you type the above line and hit return, and lldb prints something like this:
Breakpoint 3: where = Foundation`NSLog, address = 0x32a3da08
At this point, you resume your app, and it will pause again when NSLog is called (pay attention to the call stack using the Debug Navigator).
In MS visual studio we just right click add watch.
How does one do this in Xcode?
Use the po command in the Debug area
Set up a breakpoint on the relevant area of code, then when the program stops at the breakpoint, enter commands in the Console in the Debug Area.
The relevant command is po (print object) followed by the expression you want to evaluate.
If the Debug window is not visible in XCode, you can show it via the top menu:
'View' -> 'Debug Area' -> 'Activate Console' (XCode v8.x)
Example
To evaluate an expression like var1/var2 where var1 and var2 are both doubles, enter the following in the Console:
po var1/var2
The Console will return something like:
(double) $2 = 3.085 [no Objective-C description available]
Showing object properties
You can also return a particular property of an object currently used in the code at that breakpoint:
po [bankInfo city]
And it will return something like:
(id) $4 = 0x000069e8 Testville
Note though that the Console doesn't seem to like the dot notation and prefers the square brackets when applicable. For example, this returns an error for me:
po bankInfo.city
I hope this is what you've been looking for.
Gabe's answer is almost there but missing one crucial detail: Select Debugger Output . By default the bottom option is set to Target Output, so the po command doesn't show you anything.
Here is a sandwich app from a tutorial I'm debugging:
Being an xcode newbie and coming from a MS Visual Studio Background, I wanted exactly what the OP was looking for. While playing around from reading Gabe's answer I selected Debugger Output and got what I wanted.
My seniors told to use NSLog(#variable)..........
Set some breakpoints in the begginning of the looping and functions. Once u click on the breakpoint(one similar to arrow) button in the editor window the "Build and debug tool" will get enabled. You can then go to the debugger by clicking the debugger icon. on the right of the debugger window variables will be visible select self->then the instance variable u r going to set watch point.Right click on that and select "watch variable".A trigger point will be set and you will be notified with the value of the variable when changed.
As fas as i understand you would like to see when a variable is changing. For this make a breakpoint and right click on it and choose Edit Breakpoint. A window will appear:
Make sure you choose the right action like Debugger Command or Log Message and check the tick down at the options Automatically continue after evaluating. So you get some kind of action (e.g. logging, sound, etc) and wont stop at the breakpoint.
If you want to know when the variable changes, use a "watch":
Set a breakpoint somewhere in the class in question;
Run the app in the debugger and let it stop at your breakpoint; and
Go to the "Variables" view in the left side of the bottom "Debug" panel and right click on the property in question and choose "Watch".
For example, here, I've stopped at a breakpoint in viewDidLoad, and added a "watch" for total:
(This is Swift, but the same is true for Objective-C, too.)
Now, if I "continue" execution (), Xcode will pause whenever this property changes and I can see at what line of code total is changing, the stack trace to get to that point, etc.
I come from a .Net world so I'm used to just hovering over a variable while debugging and seeing what its value is.
In Objective-C I am incredibly confused on how to do that.
If I hover over it, I get a small popup with lots of information...that doesn't help me at all.
For example, I have an object called "myServer" and it is an instance of a "Server" that I have created through CoreData. One of its properties is "root" which is a simple NSString.
I cannot for the LIFE of me figure out how to view what the value of [myServer root] is.
Can some please give me some advice on this?
In the gdb console, type
po [myServer root]
I like to use GDB from the command line. Open a terminal and type
gdb
attach <your process name>
(be sure your program was built with debugging symbols). Then, when your variable name is in scope (e.g. when you break somewhere relevant) type
po variableName
to view its contents.
Another nice way to deal with this is to log directly from a breakpoint.
To do this, create a breakpoint after the value you want to see has been set, then edit it. Add a breakpoint action of 'log', and put the expression you want logged within a pair of # symbols. Check the box to the right, ensuring that the breakpoint doesn't actually cause a stop. The value will be output to the debugger console on doing a run & debug.
Doing it this way you (a) don't clutter your source, (b) can dis/enable the breakpoint at will according to your immediate needs, and (c) don't need to stop execution.
This and other very handy xcode tips can be culled from Joar Wingfors' 'Debugging with Xcode' talk.