I have a problem with eclipse debugging. I had a proper working code and few hours ago I add one more external library to do something new. When I run the program now it works properly, but when I want to debug it, it stopped on the first line of a new part of the code (the one using the newest external library). It shows the info:
"Class File Editor
Source not found
The source attachment does not contain the source for the file ModelBuilder.class"
When I try to step over I just receive the same information but connected with other files. After stepping over a multiple times I finally get back to my code and can debug the rest of the program normally.
Of course I can do it always but does anybody know the solution to that problem, not to click step over multiple times but debug normally?
It should not enter the external library code unless you step into it, or there's an exception in that code. If you find yourself stepping through code you don't have source to, use Step Return, which jumps to the end of whatever method you're in.
If it is caused by an exception in the library code and you want to ignore it, go to Window > Preferences > Java > Debug and uncheck "Suspend execution on uncaught exceptions".
If you know what exception is causing the execution to suspend, then you could also try this:
Go to the Debug perspective
Open the Breakpoints view
Click the J with the exclamation point by it (J!)
Search for the exception that triggers the debug suspend
Uncheck the two check boxes
Say OK
Related
Hi I am going to dig a little more in Java so I would like to see how the program executed in the core class. For example, I would like to know how String.chatAt() is implemented, so I set breakpoint and tried to step into with debug mode. But I failed, I set bp at the second line when the program hit it, I used step into it still continue to the third line.
String a = "1231231241241";
char b = a.charAt(0);
System.out.println(b);
I think it should go into the source and show "no source found" and then give me a chance to attach the source file, right? But why it cannot get in? I can only use ctrl+right click on a method to get into source and attach.
It might be that your Eclipse is not setup to run with JDK, it might run with JRE instead.
Check this link.
Also, I might suggest you to try and use Maven for your Java projects management, it makes the life so much easier, when you get a grasp of it.
Most likely, you have the "Step filtering" functionality activated.
When debugging, it can sometimes be a bit annoying when the debugger steps into trivial classes whose internals you were not really interested in. Because of this, you can configure "Step filters". Classes or packages that are added as step filters will be ignored by the "Step into" operation.
If you want to configure which classes/packages should be included in the step filter, you can go to: Window --> Preferences --> Java --> Debug --> Step Filtering
My guess is that you have a java.* package filter defined there, meaning that the debugger will never step into any class within a package which starts with "java". Uncheck this package filter if you want to be able to step into java.lang.String
Alternatively, if you want to activate/deactivate step filtering completely, you can do this by clicking the Use step filtering button in the debug view, as shown below:
To be able to look at the code of libriaries you are using in your project you should configure your build path by attaching the soruces and JavaDoc.
Source Lookup
Seems like you dont have the "Source Attachment" set. Go to Preferences -> Java -> Installed JREs. Select the JRE you use and click "Edit", then set the Source Attachment to the src.zip that comes with the jdk by selecting the jars and clicking "Source Attachment" :).
You can do this with all of the jars at the same time by selecting them via shift-click.
for example in this System.out.println("test") piece of code if you want to step into System class just click on System and click F3 you will be redirected to attach the source code if you haven't already attached.Just attached the src folder of the jdk
I'm using GDB to debug a program in Eclipse CDT 8.1.1. It works fine, until I try to enter a template method. I then get a "no source available for ..." message and can no longer view the code, and I am forced to either go up the stack or switch to instruction stepping mode.
If I try to place a breakpoint inside the function itself, the program halts there, but it still loses sync with the source. In any case, the sync returns when I leave the template function.
How can I solve this, to enable me to properly debug template methods?
Sometimes when I debug in eclipse, move the mouse on the parameter, no debug info like value and something else displayed but description of the parameter like the pic follow:
Sample is the aspectJ .aj source code I debugged.
Anyone can tell me why sometimes no detail info and how to fix it?
This could be an AspectJ specific issue: try installing the AspectJ Development Tools for Eclipse and see if that helps.
I think I found the solution. Whenever you run into this issue, Go to debug perspective. You will see thread will selected as parent process. Change the thread selection. Assign it to the thread which says Suspended as has your breakpoint line number. By doing you will get back all your debug values and debug commands like step into , step over etc.
When I debug a Groovy/Grails program in STS, the first time in a session that it hits a breakpoint it asks me where the source code is.
When I click on that dialog, I need to add my "Project" and then it will work until I exit STS and restart.
(But for DEBUGGING only! Lines of code mentioned in the console, whether or not they're displayed as links, will NEVER display the source when clicked on.)
1) How do I make it remember it forever? I looked through all the properties/settings I could find.
And
2) How can I click on an line of code that's mentioned in the console window (say an Exception) and have it automatically go to that line? (Micsosoft Visual Studio will do it...and it's never had to ask me where my source code is. In my 15 years of using it....)
Not everything gets hyperlinked, and even when it does, it will never find the source code, even though I can navigate to it in the Project or Package explorers:
I can answer the second part of the question here. If you see a reference to a stack frame in the console window and it is not there is no hyperlink (often the hyperlink exists, but in certain situations it will not be), then you should select and copy the stack trace and paste it into a Java stack trace console:
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.