VSCode debugger conditional breakpoints - visual-studio-code

I am currently debugging a python project, and I would like to add conditional breakpoints similar to the conditional breakpoints in Visual Studio. Is this feature supported and if so, how do I create one?

Yes, this is described in detail in the VS Code Debugging docs
In short, right click on an existing breakpoint and select "Edit breakpoint", or right click on the breakpoint margin and select "Add conditional breakpoint".

With VSCode 1.52 (Nov. 2020), you also have:
Breakpoints View: Conditions for exception breakpoints
We now support editing conditions for Exception breakpoints from the BREAKPOINTS view using the "Edit Condition" context menu action.
For now, only the Mock Debug extension has a (fake) Exception Breakpoint condition support, but soon other debug extensions will follow - such as the Javascript debugger.
That applies to Node debugger in VSCode 1.53 (Jan. 2021): see issue 104453
It is now possible to edit conditions for exception breakpoints and function breakpoints using the inline Edit Condition action or the new context menu actions.
Using conditions it is possible for the user to specify that the program should break on an exception only when a particular condition is met.
Currently the Javascript debug extension support conditions for exception or function breakpoints and soon other debug extensions will support it as well.
VSCode 1.55 (March 2021) will add:
Inline menu to edit condition and hit count
We now show an inline menu for editing conditions and hit counts for function breakpoints.
Previously the inline edit button would choose automatically what condition to edit, now the menu should make the flow easier and give more control to the user.
Access types of data breakpoints
Data breakpoints now support more access types to break on:
Break on Read: breakpoint will be hit every time a variable gets read.
Break on Access: breakpoint will be hit every time a variable is accessed.
As a reminder, data breakpoints can be added from a context menu in the VARIABLES view and we already supported Break on Value Change.
For now, only the Mock Debug extension has (fake) Data Breakpoint support for all three access types, but soon other debug extensions will follow - such as the Java extension.

if for some reason you cannot make conditional breakpoint to work follow below approach.
write if statements in your code and put breakpoint inside it.
if(condition): # condition when you want to program to stop
print("pause execution here") # put a breakpoint on this line.

You can use c++ functions.
I used this to partially match a string in a variable for conditional breakpoint with an expression:
variable.find("string")"

Related

Event listener breakpoints in Google Chrome Devtools

Event listener breakpoints in Google Chrome Devtools offers various number of options, but for me, they are not really of great use since they always throw me to some irrelevant part of code.
What I would like to know is if it is possible to limit it to just one class? For example onMouseClick send me to the 1st method that executes after mouse click, inside specific class. If none of the methods are fired inside this class, than simply do nothing.
You can set the breakpoints for each script and each line individually.
First open the debug-tools and chose a script in the sources-tab:
Then you can click on the line-number (here only no. 1) and it looks like this:
As you see now is the line marked, but also in the right col your individual breakpoint is listed.
After having marked the breakpoint you still have to reload the page that the scripts are executed again till to the breakpoint. Afterwards you can use the icons above the right col to step in or step over the commands following the breakpoint.
Having minified scripts, breakpoints are hard to use, so it's better to have a script where each line has only one command, it's much easier then to debug.
So for debugging you should change the corresponding script in your page to the non-minified version, perhaps also with a map-file if available.

Why is mouse click event listener breakpoint hit in a blackboxed script in Chrome?

I am trying to find out which Javascript method is called when I click a button. I have blackboxed some third party javascript files. I am using the latest versions of Chrome and Canary.
I have enabled the Mouse click event listener breakpoint in devtools. When I click a button, a debugger breakpoint is hit inside a js file which is blackboxed. I am using a third party button whose JS click event handler executes first before mine. I have blackboxed their code file hoping that my code gets the breakpoint. A 'This script is blackboxed in debugger' yellow message shows up for their code file.
Why is the breakpoint hit when the script file is blackboxed?
I created a test where I added a click Event Listener Breakpoint on this page and it paused in jquery-min.js. I blackboxed that script and tried again. It didn't break in jQuery anymore.
I re-read your post and you mentioned 'a debugger breakpoint is hit'. I now take that to mean an explicit breakpoint like a debugger; statement in the source code or one set in Dev Tools (by clicking line number), and that the Event Listener Breakpoint is irrelevant.
If you have a debugger; statement in a library that is blackboxed, the breakpoint will still be hit. You can disable the breakpoint by right clicking on the line number where the statement exists and selecting 'Never pause here'.
As it stands, if you put a breakpoint in a blackboxed library via Dev Tools, it will still break in that script. It shows more explicit intent to break on the code, rather than something perhaps left in by a 3rd party. You would have to disable or remove them.
There appears to be a debate about whether blackboxing a script should ignore breakpoints set in that library, as blackboxing could be considered to be more about not stepping into the library code/seeing it in the call stack. See the discussion here. Interestingly, the documentation includes the following still:
The debugger will not pause on any breakpoints set in library code.
https://developer.chrome.com/devtools/docs/blackboxing
This isn't the case.
There is come inconsistency here with the behaviour and documentation. I will try and get an update on this.

Breakpoints grouping and naming in eclipse and Visual Studio

I work with large project having different modules, subprojects. When I am working with one module I need to create set of debugpoints/breakpoints to debug that module.
When I have to work with other one, to debug it, I have to create another set of breakpoints and disable the ones created to debug the earlier module.
When I want to debug (dont conclude that I write buggy code...its just that....it just happens :p) third module, I have to create thrid set of debug points, disable the earlier two sets corresponding to earlier two modules.
Same with debugging fourth module.
Same with debugging fifth module.
Now I want to come back to debugging first module. I have breakpoints related to all modules in my breakpoint window. Say 5 breakpoints corresponding to each module. Total 5*5 = 25. Now I have to go through reading each breakpoint checking which belongs to the first one, enabling them and disabling others.
Am I missing something. Is some simpler/standard way to ease this already there in eclipse.
I feel there should be say "Save set of breakpoints" option which note all the breakpoints currently in the breakpoint window as belonging to same set and will then ask us to give name to that set, say in my case "Module 1".
Then another option "Create new breakpoint set", which will clear up breakpoint window without deleting already created named breakpoint sets
Then, ofcourse the option to "Load breakpoint set" which will simply show up the set we saved as, say in dropdownlist. We select the named breakpoint set and it will end up loading those set of breakpoints.
Q. Am I overthinking? Is similar stuff already there? Also willing to know if similar stuff is there in Visual Studio too
Use 'Breakpoint Working Sets' for this.
In the Breakpoints view (in the Debug perspective) click the small triangle at the top right of the view and select the 'Working Sets...' menu item. This will let you manage the breakpoint working sets.
More details in the Eclipse help

Is there a plugin for Eclipse that immediately evaluates a highlighted expression?

A colleague of mine uses Netbeans, and I noticed a tremendously useful feature it has in debug mode: it immediately shows what a highlighted expression evaluates to in a tooltip. I'm not sure whether this is a standard feature in Netbeans, but I would definitely find it useful in Eclipse as well.
Does anyone know a plugin or a similar way of using this in Eclipse?
EDIT:
Eclipse provides tooltips for single variable evaluation and expressions evaluation in the expressions view. This is not what I need. In Netbeans, you can highlight an expression (possibly containing more than one variable) and it gets evaluated in a tooltip.
In Eclipse debug mode you can add needed expression to Expression view and check its value or you can hover mouse over variables and check theirs values
In Eclipse, when you're running your program in the debugger, you should be able to add a Watcher for a variable, or just simply evaluate an expression (I believe) in the Watcher tab. Sorry, I don't actually use Eclipse full-time, this is just from memory as I have used it in the past...
Three years later (don't know if it was before) you can Inspect the selected expression.
Select it, right click and choose Inspect, or press Ctrl+Shift+I (personally I changed that shortcut to one more reachable F12).

Debugger / Profiler for Eclipse?

Is there any tutorial for debugging applications/ running profiler in eclipse? Please let me know thanks..
This will depend on what language you are using. How you setup for debugging PHP vs C++ is a little different as they use different underlying tools (PHP - Xdebug vs C++ - gdb)
In a general sense, you will configure the app much like you would set it up to run within Eclipse. In some cases you will have to be sure to enable debugging information within the code base for the debuggers to provide detailed information. From there you're looking at setting breakpoints, stepping, and setting up watches which is very similar language-to-language within the Debug Perspective in Eclipse.
A common scenario is to set a breakpoint within the codebase by clicking on the left bar in the editor, and selecting toggle breakpoint. Then click the debug button in the IDE and it should open the Debug Perspective and either break at the beginning of main, or will run to the breakpoint you set in the code. Once the break is hit, you will be able to browse the stack frames within one of the views within the perspective and you will see tabs for watches, breakpoints, etc. The buttons near the top that look similar to play, and then arrows jumping over dots are the way you control the execution from your breakpoint. If you click "step over" the code will go line by line in the source file you're in until it must goto another file to follow the execution of your code. It will not go into a function call, rather call it execute it and return to the next line in the current source. If you want to go into the function call and continue debugging from there, you would use the "step into" button which is right next to "step over" in most cases. Resume restarts regular execution and will run your program normally until the end or another breakpoint is hit.
Start from there and get comfortable with it and then start playing with things like conditional breakpoints and watches. Conditional breaks are exactly like breakpoints but they only stop execution if the condition you specify is met. With C++ this is usually done by right clicking on the breakpoint and providing the conditional expression where appropriate in the menu. (I forget the exact verbage)
Watches allow you to watch memory and have the program break when memory is read, written to, or both so you can inspect your application.
Some debuggers in Eclipse may lack some of these features or offer more advanced features than those listed above, but these concepts should get you well on your way.
Good luck!