Why does my Eclipse project have phantom debugger breakpoints?

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?

33806 次浏览
小开
最佳答案

Did you try to un-select 

Window > Preferences > Java > Debug : Suspend execution on uncaught exceptions

? (as mentioned in this thread, for instance)

alt text

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 "ABC0", simply sets a breakpoint for the type named "ABC1", 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:

Add Breakpoints window to Eclipse

Remove All (Breakpoints, right click)

小开

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.

小开

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.

小开

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

提交答案