As the number of breakpoints builds up during a phase of development, or during debugging a single issue, it's usually necessary to clear all of the current breakpoints when moving to another issue/phase.
Is there a way to have a 2nd Breakpoints tab, where permanent Breakpoints could be left intact i.e. for intermittent issues we sometimes leave breakpoints active while fixing numerous other issues.... this makes clearing all Breakpoints a real hassle
Brian
P.S. I'm aware of using logging instead of these longer term breakpoints
You can group and assign breakpoints in working sets to achieve this:
In addition you may export or import them to transfer breakpoints between projects or store them with your project.
Related
I have been using VSCode for a long time and I don't know how to resolve this problem.
Please don't confuse what I am asking with removing a break-point after I have added it. I simply want to disable them all together.
Here is an image of the break-points that I am referencing:
Break-points are contributed by debugging extensions. If you want to rid your self of them you need to disable the debuggers for the markdown/programming language that your coding in.
First you need to check the extensions you installed for any debuggers. I included an image below that shows how to search for them.
Right click on the debugger extensions and disable them.
Now you need to look for debuggers built-in to VS Code
To do this, refer to the next image below.
and again, right click them, then disable them.
Additional Info:
Not every debugger is going to contribute breakpoints to the language your coding in. Its likely going to be a single debugging extension that contributes the breakpoints. Disabling all debuggers will get rid of them, but I suggest that after you get rid of the break points that you go back and enable the debuggers one by one, and check and see if the break-points come back after each one is disabled. This way you can find the debugger that is contributing them. Then disable only the debugger that is adding them, and leaving all other extensions enabled, as some features rely on them.
It looks like your writing a markup language, specifically either standard HTML, or XML (probably SVG). Those are not debuggable languages, so some extension is probably needlessly contributing breakpoints. Which means it might be a debugger you installed.
EDIT:
As an FYI, you should also make sure the setting "debug.allowBreakpointsEverywhere" is set to false.
go click on the run part on tab and select remove all breakpoints
When running my code in debug mode, I keep getting 2 error messages:
Could not delete [path_to]\productiondb.log. May be locked by another process
I don't know what process might be locking it. It comes when I make changes to the code while my Pivotal tc Server is running in debug mode, but it dosent seem to create a lot's of trouble. Sometimes however, I get this warning:
Also due to some changes. I usally just restart the server and move on. This isen't the real problem, the real problem is that I get these messages when I havent doen any changes. Somethimes it accures when I run a certen part of the code, other times i occurs when I open certen codes in sts, however, it doen't seem to stop at the same place twice.
I am suspecting that this has something to do with git. I am using git to change between versions and doing tests. So I am thinking that STS has some of the code in memory from before I changed branche with git, and isen't updating it before I run or open the file with that code. But I am rather new to both sts and git, and can't be certan that it would work that way. If it is, does anyone know how to update sts after I have changed branch? If it is not, does anyone know what might causing it?
If you run an app in debug mode, the Eclipse Debugger tells the application when code gets changed and tries to use the debug API to swap in the new code into the running application. This is especially useful if you debug your code, hit a breakpoint, step through the code, fit the issue, change the code, and press save. At that moment, the Eclipse compiler updates the class file and tells the running JVM to swap in the new code. If that succeeds, the debugger will jump back to the last stack frame and the execution of your app will continue with the beginning of the method that you entered. This allows you to directly continue to debug and step through the updated code without restarting the app.
While this is a great feature of the JVM, it is very limited in terms of what scope of changes to the classes the JVM can deal with while doing this hot-swap. It is usually limited to method implementations. So adding new methods, adding or deleting members of the class, etc, are not supported. As a result, the above screenshot will appear. It means that the JVM wasn't able to hot-swap the changed code and will continue to run with the previously loaded code instead of the changed one.
I'm not sure if workspace is the right terminology but I am using Katalon and have 2 irritating issues debugging. I suspect they are related..
1) Old breakpoints that have been cleared are being hit quite often (I've cleared some more recently and they are properly cleared so I wondor if there is a point in time where some were not emptied out properly)
2) One test case/script that gets called by a test suite is showing a different script when being debugged. This is very odd as it is actually running the right script in code but is sowing a different one and stopping at unrelated break points.
Is there a way to clean Katalon degug config out in some way?
Has anyone else experienced this ?
Yes, Katalon has a degug option that you can try: file > Clean.
You can try to read more here.
I followed this tutorial and got Eclipse to recognize the program I'm debugging.
However, after setting a break point, and steering the application to the break point, the application just seems to ignore it.
The code continues merrily as if nothing happened, and I don't get to see the variables I'm trying to look at.
Unfortunately I don't know what info to include here, so if you need more information, just let me know in the comments.
You have to be careful with what you are doing. There are some pitfalls when debugging node applications in eclipse. Here are some tips that might help you.
Start your application with node --debug-brk your-script.js
Start the debugger in eclipse
Step over (F6) the first few require statements, that import the code you want to debug.
Set your breakpoints. (Be sure you don't set breakpoints in the source files you are currently editing. When debugging, there is a "Project" in your workspace that contains all the scripts that are loaded by node. Set your breakpoints in some of these files. Otherwise the breakpoints will be ignored. Most often you want to set breakpoints at the beginning of a callback.)
Then resume (F8) the script and it will pause at the first breakpoint it passes.
Start with that until debugging works for the first time. After that you can try more unconventional cases.
I've got a small project which, when run in the Eclipse debugger, always seems to stop in FileInputStream.class line 106, where files are opened. There are no breakpoints set, but Eclipse behaves exactly as if I have a breakpoint here. If I clear all breakpoints, it still happens.
I have a second much-larger project in the same Eclipse workspace which does not suffer from this problem.
I just moved the smaller project off of my old Linux machine, where I developed it in Europa Eclipse and had this problem, onto my new Windows machine, where I continue to see the problem in Ganymede Eclipse. The problem persists across operating systems and across Eclipse versions, yet apparently not across projects. I don't get it! I grepped through every file in this project's directory and couldn't find anything that might be a file somehow directing Eclipse to stop in FileInputStream.
Further info: the apparent breakpoint is actually not for line 106 of FileInputStream; it appears to be an Exception breakpoint for FileNotFoundException, being thrown from native code called from that line in FileInputStream. But again, I don't appear to have any breakpoints set at all. Are Exception breakpoints defined somewhere else?
Did you try to un-select
Window > Preferences > Java > Debug : Suspend execution on uncaught exceptions
? (as mentioned in this thread, for instance)
Why does Eclipse work that way?
It goes back to 2002, when the breakpoint object hierarchy has been stripped down.
In order to set a breakpoint, with the old API, a client required Java Model Objects - such as IType, IField, etc.
With the new API, all that is required by the debug model is type names, field names, etc.
This allows clients to set breakpoints when Java Model Objects are not available.
Clients now specify the resource to associate a breakpoint with (before we constrained it to the associated Java Model resources).
Breakpoints can now also be "hidden". That is, they need not be registered with the breakpoint manager.
Breakpoints can also be selectively persisted (markers only allowed all/none of a marker type to be persisted).
This makes the debug model more flexible, and gives clients more building blocks.
This has also simplified some part of our Java debug implementation - for example, the feature "suspend on any uncaught exception", simply sets a breakpoint for the type named "java.lang.Throwable", rather than a specific IType in a specific project.
The breakpoint is not registered with the breakpoint manager (i.e. hidden) - it is only known and used by one client.
Another example is the "run to line breakpoint". The IJavaRunToLineBreakpoint has been removed, as its special functionality is no longer required. Now, the Java debug ui simply creates a "line breakpoint" that is hidden, non persisted, and has a hit count of 1. This is an example of providing building blocks to clients.
I had a similar problem but the accepted solution did not work for me. I am doing Eclipse Android development and had set some breakpoints and later unset them. Even though I disabled them Eclipse kept stopping execution at these phantom breakpoints. The solution for me was to open the Breakpoints window:
Window > Show View > Other...
Debug > Breakpoints
Then right click any breakpoint and select "Remove All"
Unfortunately you have to reset all your valid breakpoints, but this worked for me and has prevented much angst and frustration going forward.
Some pictures to guide others:
For those who don't find other solutions useful, I found my personal solution to my problem. I work with a .jar library which is generated by building another project into the workspace. If I set a breakpoint in a .java into the library project, then the breakpoint will be triggered when debugging the final project. However when debugger pauses the execution the .class file is shown which has its own breakpoints and therefore the breakpoint set into the .java file is not shown here!
Solution:
In order to remove the breakpoint you have to remove the breakpoint into the .java file, in the library project.
I ran into an issue where a source file had persistent markers for breakpoints that didn't exist. I tried cleaning the project, doing a full build, restarting Eclipse - nothing worked.
I went digging through the Eclipse metadata, and found the projects .markers file. Deleting that file finally fixed the issue.
For anyone else having this issue, open your workspace directory, then navigate to .metadata/.plugins/org.eclipse.core.resources/.projects/your project, then rename/remove file .markers.
For example, if your workspace folder is ~/workspace, and your project is named Foo, you could do:
$ mv ~/workspace/.metadata/.plugins/org.eclipse.core.resources/.projects/Foo/.markers ~/safe.Foo.markers
For those who didn't find a solution from the previous answers, they can try what solved my problem. It is I think similar to HAL9000 problem/solution
If you have two classes with the same name (in two different projects) the breakpoints on the one, apply on the other one as well. Both of them show in the "Breakpoints" window.
Solution: If you remove the breakpoint from the class - with the same name - that you are not using it removes the breakpoint from the class you are debugging.