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.
Related
This is not another of many "how do I have Eclipse auto refresh" questions. My problem is that it does but not entirely.
In a workspace with multiple projects the compilation of one causes source code to be generated in other(s) (that exist purely for this purpose - no manually written source code there). Source code is generated during the main compilation itself (i.e. not a custom builder, but a plugin for the Scala compiler, but that should be irrelevant).
What I've done so far is:
Add a dummy custom (ant) builder AFTER the standard one and set it to "refresh selected resources" - the source folder of those generated projects.
Also add a dummy custom (ant) builder BEFORE the standard (Java) builder of generated projects that refresh the same thing. Actually I tried various versions - just the source folder, the entire project, or the entire workspace with the same outcome. Note that those generated projects are set to depend on the project whose compilation generates their source code.
In Window -> Preferences -> General -> Workspace enabled "Refresh using native hooks or polling" in addition to "Refresh on access". I also tried disabling "Refresh on access" (leaving only the other one). Same outcome.
Tried with Eclipse Indigo (3.7 SR2 20120216-1857) and Juno (4.2.2 M20130204-1200), both 64-bit Windows versions. Additional plugins are installed, most notably Scala IDE (multiple different versions both for Scala 2.9 and 2.10 ending with Scala IDE 3.0.0). Same outcome.
... and that outcome is that Eclipse does indeed notice the files that have been modified. In whatever was the best combination of settings of the above (forgot) I was even able to get it to notice that some files that used to be generated no longer are and have them disappear (although I still had to collapse the tree and re-expand it, but no F5 was needed).
However, I never got to have it automatically discover that a brand new file that did not exist before was created. In my case that also yields compilation errors (since the modified files that it does discover have changed refer to the code in new files it does not notice).
Simple F5 solves the problem, but it is killing me, as I am trying to roll this environment to other developers and I'd hate having to tell them "You know, you have to (keep) push(ing) F5 every time you...".
Is it possible that this is still impossible in Eclipse? Does anyone know of a plugin (if not a direct solution) that can help?
As I noted in comments, discovering new folders (Java packages) also does not seem to be a problem. Just new files in existing folders.
Thanks!
UPDATE
With all the refresh things I did in place I noticed something I did not before.
I make the change in the project that causes code generation (was trying to test if it is the re-appearance of previously disappearing file is an issue or otherwise). This time I was just renaming one method which caused a name of the generated source file (Java class) to be changed as well.
As "Build automatically" is enabled, Eclipse begins the build. Very quickly it discovers an error and complains about it - one generated class that was modified now refers to a class Eclipse does not see yet (because refresh is incomplete - saw the modified file, but still believed that the file that no longer exists is there and did not see the new file).
Build actually continues. Progress goes up and down, appears and disappears a number of times, building other dependent projects. All the time the error is listed and marked in the Package Explorer on the modified class.
After the build seemingly completes (with that error in it, some minutes later), the refresh completes (!!!). Package Explorer is updated, the old file disappears, the new file appears, the error disappears, etc. I initially attributed this to me switching windows and triggering the refresh that way but I made sure I touched nothing the last time - just made the change and pushed Ctrl+S to save it.
This may mean that the 'condition' is not so bad (one just has to be very patient and have nerves of steel). Investigating further. Thanks to all who are or may be doing the same! The question is still why are there two refreshes with the first one being incomplete?
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
I develop Java code with Eclipse and regularly get this message:
resource is out of sync with the filesystem.
Right-click > Refresh will always clear this.
But why can't Eclipse refresh automatically when it finds this condition? Are there cases where you want the resource to be out of sync?.
If there are such conditions and they don't apply to my work, is there a way of getting Eclipse to refresh automatically when it encounters this state?. (I appreciate that it should refresh as little as it needs to in normal development to increase performance for human developers.)
UPDATE (2012-06-25):
My latest update (Version: Indigo Release Build id: 20110615-0604)
no longer shows
Preferences - General - Workspace - Refresh Automatically
There is an option "Refresh on access" - should I use this?
You can enable this in Window - Preferences - General - Workspace - Refresh Automatically (called Refresh using native hooks or polling in newer builds)
The only reason I can think why this isn't enabled by default is performance related.
For example, refreshing source folders automatically might trigger a build of the workspace. Perhaps some people want more control over this.
There is also an article on the Eclipse site regarding auto refresh.
Basically, there is no external trigger that notifies Eclipse of files changed outside the workspace. Rather a background thread is used by Eclipse to monitor file changes that can possibly lead to performance issues with large workspaces.
Just right click on the file or on the project and click Refresh. The error will vanish. I also faced the same issue and it worked for me.
Window -> Preferences -> General -> Workspace
For the new Indigo version, the Preferences change to "Refresh on access", and with a detail explanation : Automatically refresh external workspace changes on access via the workspace.
As “resource is out of sync with the filesystem” this problem happens when I use external workspace, so after I select this option, problem solved.
This happens to me all the time.
Go to the error log, find the exception, and open a few levels until you can see something more like a root cause. Does it says "Resource is out of sync with the file system" ?
When renaming packages, of course, Eclipse has to move files around in the file system. Apparently what happens is that it later discovers that something it thinks it needs to clean up has been renamed, can't find it, throws an exception.
There are a couple of things you might try. First, go to Window: Preferences, Workspace, and enable "Refresh Automatically". In theory this should fix the problem, but for me, it didn't.
Second, if you are doing a large refactoring with subpackages, do the subpackages one at a time, from the bottom up, and explicitly refresh with the file system after each subpackage is renamed.
Third, just ignore the error: when the error dialog comes up, click Abort to preserve the partial change, instead of rolling it back. Try it again, and again, and you may find you can get through the entire operation using multiple retries.
If this occurs trying to delete a folder (on *nix) and Refresh does not help, open a terminal and look for a symlink below the folder you are trying to delete and remove this manually. This solved my issues.
When you open an Eclipse workspace from within a clearcase view and try to rename the project, you will often get the pop-up warning ... “Resource ‘project’ is out of sync with the file system”. If refreshing the project does not fix the problem, then do the following workaround: a. Open workspace WITHOUT being in a view b. Select the project in Project Explorer c. ClearCase -> Associate Project (project should now look like project [] ) d. Right click project -> Refresh (vob sub-folders should now be empty) e. Right click project -> Rename ... f. Enter New name
Now you can close the workspace, reopen it in a view and refresh the project. You may also dissociate the project if you prefer the project not to be associated with the vob.
A little hint. The message often appears during rename operation. The quick workaround for me is pressing Ctrl-Y (redo shortcut) after message confirmation. It works only if the renaming affects a single file.
If you are a regular Eclipse user than you might have got this error many times. The error simply says, “you’ve made changes in files in your workspace from outside eclipse”. The simplest solution would be to select the project and press F5 (Right click -> Refresh).
if you need more explanation you can read from this web site
I was not able to resolve this error by either refresh or by turning on "native polling" workspace feature. Turned out my project was also opened in two instances of eclipse. Once I closed the other instance, the error went away. So make sure your project is only opened at one place if you are seeing this error.
I am SOOOOO discouraged. This seems so simple, but being a complete novice in Drupal and Eclipse PDT I have absolutely no idea where to look. My DAYS of searching seems to indicate that I am the only person on the planet with this problem.
Eclipse IDE for PHP Developers (1.2.1.20090918-0703)
WampServer Version 2.0
Apache 2.2.11
PHP 5.2.9-2
MySQL 5.1.33
Drupal 6.15
xDebug php_xdebug-2.0.5-5.2.dll
I setup my project in Eclipse to point to my Drupal directory (C:\wamp\www\drupal-6.15). I start the debugger (xdebug) and I stop at the first line of code. I can step through the code line by line -- so I think I am in the debugger, and when I terminate the app, I see the xdebug termination message in the tab heading.
But I cannot set a breakpoint in any of the PHP code files -- specifically a new .module file.
When I right click in the breakpoint column on the left in index.php (main) I see "toggle breakpoint" and the little blue circle next to the line of code...so I think I know how to set a breakpoint. But when I try to set a breakpoint in my .module, I see a menu that asks me to "add a bookmark" and no option to set a breakpoint.
Why can I not set a breakpoint in this file? Is my project path not set up correctly? Do I need to amend my include path? I can't get Eclipse to recognize even core modules not just site/all modules. I've seen posts about "importing" files into the project, and making sure the correct php.ini file is used for configuring xdebug. I'm lost.
There are so many posts about using Eclipst PDT and xDebug and they all end with "have fun debugging" or "just set some breakpoints and off you go" -- but what if you CAN'T set a breakpoint? Any ideas about where Eclipse is lost? Where in Eclipse can you get a list of files it has included in its build?
I think I just need to know understand why Eclipse cannot find these modules within the project (i.e. drupal application) path to allow me to set breakpoints. Then I think I can carry on. So discouraging...
Thanks to anyone listening.
Thanks for the tip. I think I had seen your similar response in another post somewhere.
Actually, the solution for me was to make sure to include all of the standard Drupal file extensions in the Eclipse file associations preferences: Preferences->General->Content Types->Text->PHP Content Type. The defaults are various *.php, *.phpX, *.phtml extensions, but not the extensions used in Drupal modules -- *.info, *.inc, *.module, *.install, etc.
Simple and obvious once you figure it out. I'm surprised with all the Eclipse-xDebug-Drupal setup instructions out there that this had not shown up. Lots of details about matching project paths with server paths, but nothing about this.
I hope my struggle helps someone. I did learn a lot about Eclipse PDT along the way :-). Good luck.
Breakpoints are tricky in PDT projects:
for php files, you need to be careful
One thing that gets me a lot is that there a lot of "invalid" places where you set breakpoints. You can put the dot there in the IDE, but the debugger won't stop at it:
blank/non-code lines
on switch statements
in some types of callbacks (for example, preg_replace)
But for breakpoints in .module files, this should be related to a setup issue.
I made the following changes to my setup:
Upgraded from php 5.2.1 to php 5.2.3
Installed the Zend debugger client in Eclipse/PDT (theoretically not necessary from what I understand, but I decided to give it a try)
Made sure that the Drupal files were fully imported into my project, not just referenced as include libraries.
I did that last step after I created a tiny test case and discovered that I could get the debugger to stop on a breakpoint in an externally included file only if that file was imported into the project, not if it was referenced as part of an include library directory.
To my mind this seems like a bug - the debugger could certainly see that the files in the include library directories were source files and it let me set breakpoints in them, so it seems that it should stop on them.
(For comparison from a separate (java) IDE, IntelliJ will let you define breakpoints in jar files as long as you tell it where the source is. Once you've defined it, it will stop on it.)
I think it was principally that last step that did the trick, so I'd suggest that anyone else with a similar problem make sure that isn't an issue in their setup first, and then try the other steps.
check whether you opened your java file in java editor mode.
ie ctrl+shift+R, in this popup check the button beside OPEN option and select java editor.
The problem of not being able to set a breakpoint can occur if you have recently created a file. You must close and re-open the file for it to be recognised as a source file that can be debugged, and to enable the code highlighting.
If you press Shift+Ctrl+T or choose "Navigate > Open Type..." you get the "Open Type" dialog for quickly navigating to a known class. When you start typing a name only the classes for which the name matches stay visible. That way you can find a class of which you know the name very quick without having to browse through the package explorer tree.
This has been working great for me up until this morning. All of a sudden for a couple of my projects I am only seeing some of the types that exist. Of course I tried the obvious steps of refreshing the projects, cleaning the projects, re-building the projects, rebuilding the projects externally, but all to no avail. It is a bit odd since the types are known in other places. If I add an import statement Eclipse does not complain that it doesn't know the type and I can Ctrl-Click through the types to get to their file. However, the type navigation knows nothing about them.
In the past when InteliJ used to do this to me I would go find its cache files and delete them forcing it to rebuild. Does Eclipse have something similar I might do (I'm an Eclipse newbie)? I am using Eclipse 3.4.2 and I have it configured to not delete files on a clean (because our actual build process puts files into the output directories that I don't want Eclipse mucking with).
Have you tried closing and reopening the project? Only types from open projects are held in memory, and the refresh occurs when you Shift+Ctrl+T for the first time on a newly opened project.
Edit to add: Ctrl+Shift+R also displays the types (along with everything else) but it also supports the Camel-case thing to find the Java types quickly.
Close eclipse and delete any .index files and the savedIndexNames.txt file in workspace/.metadata/.plugins/org.eclipse.jdt.core once eclipse is restarted it will rebuildl the entire index for Ctrl+T
try starting eclipse with the -clean flag, you can add this to your eclipse.ini which can be found in the same directory as you eclispe.exe, or if you start eclipse using a bat or shell script, add it as a startup argument, e.g. eclipse -clean.
The clean will tidy your workspace, and should force eclipse JDT to recalulate types. Ive had issue with .snap files (with seem to be created on dirty shutdowns) that seem to corrupt my workspace until I clean them up, not long ago eclipse lost the Object class!! made for some interesting errors!
I get problems like this often. I tried your solution, noticed it seemed to rebuild its search index, but I still couldn't find any of my classes. Then I took a look at the little green arrow on top right corner of that dialog, and noticed I had a working set selected which belonged to another project. I find it a little dumb that Eclipse doesn't warn you about this or anything, since this can be a very annoying little detail that one tends to forget (me at least ;-)).
Anyways, clicked on "Deselect Working Set" and bam I can find my classes again. Thought I'd add this here since others may make the same mistake.
This worked for me -
Select your project in Package Explorer
Press F5 or Right click and select Refresh
I used the "-clean" as first line in the eclipse.ini (version Juno) and worked like a charm.
I'v tried all the answers and I still had the issue. I then tried this:
I deleted the project (it's a maven project) and re-imported it. This time I made sure i check the "Add Project(s) to working set" checkbox. After that Eclipse was able to find the classes in that project.
The problem must have started because I didn't check this checkbox when i first imported this project.
By the way, I'm using Neon
(Warning: Shameless marketing ahead)
If you like this feature, you would love nWire. nWire allows, among other things, to quickly search not only for types, but for any possible Java element like method or field. It also uses a navigator view which is non-modal. After searching you can see the class associations in a very quick and easy way. Check out the video on our site.