for some internal development I currently customize a Eclipse Plug in. The Plug in I use is deployed as .jar File. Now I extracted the Content and imported it as Eclipse Plug in project. Everything works fine until is start to add some Code.
For testing the new functionality I like to debug my code. Therefore I run the Eclipse Plug in project in Debug mode. I've got a Debugging connection but the line of code highlighted in the editor doesn't match with the code.
1 private void a(){
2 doSomething();
3 }
4
5 private void b(){
6 doSomethingElse();
7 }
For example the Debug view says I am in the Method b(). But the Highlighter, in the Text-Editor, point to line 3.
I tried several things like Cleaning and searched nearly everywhere in the Debug-Configurations but nothing helped me.
If the displayed code doesn't fit what the debugger tells you it is executing, then you are simply not debugging the code that you see in the editor (but probably still the version without your modifications).
There are a lot of potential reasons for this. For the most easy failure please check your debug configuration. On the plugins page of the debug configuration there are plugins shown as living in your workspace and being provided by the Eclipse installation. Make sure that for your plugin the checkbox is at the workspace version, like the first checkbox in this image:
The debugger highlights the code that is just about to be executed. When the debugger says you are in method b() it is simply telling you that it is about to debug method b()
Related
While trying to use GWT Super Dev Mode, I followed those guidelines :
GWT-2.5-Super-Dev-Mode
Introducing Super Dev Mode
How does GWT's Super Dev Mode work?
However, I am stuck at the step trying to turn on Super Dev Mode :
Once I fully compiled my project, I run the code server and the dev mode, go at http://127.0.0.1:8888/myapp.html (without the ?gwt.codesvr=127.0.0.1:9997) and then click on the bookmark Dev Mode On. It detects my module, asks me to recompile, a glass screen appears with a message Compiling MyApp ... and then nothing ... No error, no stack trace either in Chrome or Eclipse. Just nothing happens.
Debugging the js code from dev_mode_on.js file, the script is interrupted at line 324 :
...
function getBindingParameters(module_name, get_prop_map) {
var session_key = '__gwtDevModeSession:' + module_name;
--> var prop_map = get_prop_map(); <--
...
Once the function get_prop_map is called, a few more obfuscated functions run and the debugger returns.
I know it is still experimental, but do you have any idea of what I could have done wrong ?
PS: I am using GWT 2.5, GWT-maven-plugin 2.5 and Chrome 23.0.1271.64 m
We have found a similar issue and tracked down the cause, looks like a boundary case not handled in GWT.
More info can be found here: http://code.google.com/p/google-web-toolkit/issues/detail?id=7894
I don't have an answer, but I can give some general debugging tips for this sort of problem.
Super Dev Mode currently (as of 2.5) doesn't report any progress to the web browser while it's compiling. It won't update the dialog until the compile finishes. So it's possible that it's just very slow for your program for some reason, or the compile stopped and somehow didn't report an error like it normally does.
However, there are other ways you can monitor its progress. The compiler log is available as a web page by following links from the code server's front page; you will have to refresh the page to see updates. Or you could look at the log on disk in the code server's work directory. (You can set the work directory with the -workDir argument when you start it.)
Another way is to start the code server from the command line. Any stack traces from the code server will be printed there. You should also be able to look at the output in Eclipse or IntelliJ if you're running it from there.
From this you should be able to tell whether the compiler is slow, but still working (it's still printing output) or has actually stopped with a stack trace.
I am using Eclipse IDE (Helios Version)
While debugging in Eclipse , is it possible to edit the source and continue debugging ??
For example i have this file
While debugging when i tried to modify the a4 value during debugging its not reflecting ??
public class Tes {
public static void main(String args[]) {
int a4 = 15;
for (int i = 0; i < a4; i++) {
System.out.println(i);
}
}
}
Yes it is possible to edit the source and continue debugging in Eclipse! You'll find extensive information here: Debugging with the Eclipse Platform (scroll down to the section Hotswap Bug Fixing: On-the-fly code fixing).
If you are running Java Virtual Machine (JVM) V1.4 or higher, Eclipse
supports a feature called Hotswap Bug Fixing (not available in JVM
V1.3 or lower). It allows the changing of source code during a
debugger session, which is better than exiting the application,
changing the code, recompiling, then starting another debugging
session. To use this function, simply change the code in the editor
and resume debugging.
There are some cases where the feature will not work. E.g. if you make changes to your main method's a4 variable, the JVM will not be able to remove all stack frames running old code from the call stack. The debugger data will be lost.
To see the Hotswap Bug Fixing JVM feature in action, just move the code from your main method in the Test class to some other class. Here's what I mean:
Now you can modify the code on the fly while debugging in the MyObject class. Have fun!
EDIT: Just found a similar question at superuser.com: Debugging in Eclipse, how to run until a breakpoint
If you happen to be running your application using a 1.3 JVM or higher versions, there's one final step with the debugger still running:
-> change the problem line - in your case "a4 value" and then Save the file, then press the Resume button to get the application running again.
This Saving of that particular java file that you have edited during debugging, will make the session to continue debugging from start(Constructor) of the file with new values.
This editing and saving can be done n number of times, and once you save it, the debugging session will automatically resume from the start of that particular file.
If you just want to change the value of a5 during debugging its alot easier than changing the source.
You can set a new value in the variables view you can see when in the debugging perspective in Eclipse.
See the manual here and here
Being new to NetBeans 7 (this is running on Windows 7 64-bit Ultimate Edition) I found it extremely interesting that I can't get any POC (proof of concept applications) to be "viewable." Allow me to explain.
Going through the tutorials - about as simple as anything can ever be in software dev:
1) I create may NetBeans Development application ... but using a product location other than the default. NetBeans wants to use C:\Users{user_name}\Documents\NetBeanProjects as the root path to your projects, then create project folders underneath. Reasonable, but I have dedicated "development drives" where all my development happens, which is not where NetBeans wants to put it.
2) Create a Module for the application. Here I created an Installer and placed a System.out.println() in an overriden restored() method .... you never see this in the Output windows of the IDE. I also added a new Window with a button and textArea, and set the new Window's properties to be shown on application startup and in the Editor location .... you never see these either.
Long story short, I uninstalled NetBeans v7.0 from the computer, and reinstalled it again, but this time allowing the IDE to use the location it wants for project folders. Though, I still do not get the System.out.println() text in the Output window, I do get my new Windows with the button and TextArea.
I've added this post because I did a bunch of seaches trying to find an answer to all this to no avail. I certainly don't have the real answer, but if someone else is strugling with the same problem you'll at least have a "partial answer" if you've changed default project locations and your applications "don't seem to run or be visible."
If anyone knows the real answer to these questions PLEASE advise.
EDIT #1 ... thinking this might be a security or privilege issue I tried running the IDE "as Administrator" and this didn't make any difference. I do not see any prompts or anything in the OS' logs that indicate a problem either, so I'm assuming it's NetBeans.
EDIT #2 ... Found it. Finally discovered where all my System.out.println()'s are ending up. Not in the IDE's Output Window as I would have expected (pretty sure I'm not the only one) but in a "message.log" text file located at
C:\Users\{User_Name}\Documents\NetBeansProjects\{Project_Name}\build\testuserdir\var\log
That was fun - Not! I am assuming that this probably means the System.out is currently set to do this in a property somewhere. But at least I know it's not disappearing off into space somewhere now.
re. the System.out "Not in the IDE's Output Window", have you tried to instantiate a logger instead?
Directly after the class declaration, paste in the following field definition:
private static final Logger logger = Logger.getLogger("thePackageName.andYourClassNameHere");
import the import java.util.logging.Logger; library.
then simply log what ever you want to trace on the output console.
ie: logger.info(" ... " + ....);
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.