I am trying to debug an Eclipse plugin, but I can't figure out where to place the breakpoints.
Is there anyway to set Eclipse to Debug every single expression so that from the moment I execute the plugin, the first expression is a breakpoint?
If you have an Activator class, you can start with that. Otherwise it's really a matter of what extensions you're contributing and when those will be called by someone else. Plug-ins aren't like applications. Set your breakpoints in your code, they'll trigger when code from your plug-in is triggered.
A plugin is more than code and the code it might have doesn't need to be Java, but if it's Java code you want to debug, try setting class load breakpoints on all of your plugin's classes.
Related
I frequently use folding/unfolding of methods in Eclipse for Java while working. However after each launch of Eclipse I need to redo the settings of folding/unfolding methods. Is it possible to make the framework "remember" my settings in each opened file? By folding/unfolding I meen clicking (+)/(-) button as on the following picture:
Please note I do not want all methods to be folded or all to be unfolded. I want the fremwork to remember my settings.
Although Eclipse doesn't natively support the remembering of folding/collapsed state of its editors, you can use external plugin to do the same. Here's a plugin that might help you with your problem.
Eclipse Folding Plugin
I am using Eclipse IDE for Java Developers
Version: Helios Service Release 1
Build id: 20100917-0705
In remote debugging Web app with tomcat 7.0.37, when I make some changes, even a line, the changes can not be made into the runtime, so I need to recompile and re-deploy the war application. Wast a lot of time. The message:
Hot code replace failed - Delete method not implemented
I do not understand the message.
Anyone know the secret on how to auto reflect the code change in debug mode? Thanks.
I've found that for hot code replacement to work the code being modified/replaced must be in the execution stack. So you can hot replace changes made to a method you've stopped in, but you can't hot replace changes to that method once you step out of that method... unless you first stop back in the method on a successive call to the method.
With the standard JVM (Oracle's), you can only modify existing methods. Both adding and deleting methods, and changing structure of class (moving methods, fields) are NOT supported. For that, go to JRebel!
One thing to notice is that changes to seemingly "normal code" inside some method will actually need for the java compiler to add or delete methods - and hence it will fail. This happens e.g. if you in an inner class accesses private fields in the outer class - the java compiler will need to add synthetic accessor-methods to the outer class to let the inner class access those fields - which hence will fail to Hot Code Replace. Also, if you remove some code accessing such fields, the java compiler wants to remove the corresponding synthetic accessor-method, which also will fail.
I think there is no way to reflect the code change in debug mode
Debug mode is to trace program flow and find if any issues or errors at particular piece of code....
it just points to line of code in eclipse, which is running in your tomcat, ie. code in eclipse is not used to run application the code u have installed or put in tomcat runs
hence your changes made in eclipse cant reflect in tomcat code
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.
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.
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.