I am using IntelliJ to debug a Java program. In my current case that happens to be IntelliJ itself -- to debug a problem in it -- but a similar problem occurred in the past with other code.
While single-stepping, at a certain point when stepping into a method, IntelliJ won't show the code that is being executed anymore. I am used to stepping through decompiled byte code when source is not available, but in this case IntelliJ won't show anything -- no source code, no byte code, nothing. This happens when stepping from RemoteExternalSystemProjectResolverImpl into GradleProjectResolver.
Quite suspiciously, the problem happens exactly when stepping from a class that comes from an UrlClassLoader, into a class from a PluginClassLoader.
I'm aware that the debugger will have problems associating the bytecode being executed with source code when the bytecode comes from a class loader of unknown nature, since there is no well-defined mechanism for that. Please note that I am totally fine with stepping through decompiled code. (Even stepping through bytecode instructions would be fine, but AFAIK IntelliJ does not support that). I'm not sure how to provide matching source code myself, so I'd rather see the bytecode to be sure I'm not seeing false information.
What I do not understand is why IntelliJ won't show me that bytecode. Unlike source code, the bytecode is avaiable since after all, it is being executed right now.
What should I do to make IntelliJ show the bytecode being executed?
Update: Steps to reproduce
Use IntelliJ to create an IntelliJ plugin project
create a new folder with an empty build.gradle file in it
Run a "guest" instance of IntelliJ in debug mode
Import the empty gradle project
In the "host" IntelliJ, go to RemoteExternalSystemProjectResolverImpl.resolveProjectInfo and set a breakpoint to the inner call to this.myDelegate.resolveProjectInfo
In the "guest" IntelliJ, hit the Gradle re-import button. It should hit the breakpoint.
Step into the function being called. This will show the frame on the stack, but no code -- not even raw or decompiled bytecode.
You are possibly debugging a library that had been compiled without debug infos. For this purpose, the Java compiler has the command-line option "-g".
I assume you do not understand what bytecode is. This is a bunch of numeric values which cannot be displayed in a similar manner as source code. You would not be able to read bytecode.
What you are usually seeing is decompiled byte code, which depends on the existence of debug infos.
I was running into a curious problem today and would like to get some more info on that, as my google-fu proved to be insufficient for that.
What happened
The scenario is as follows: I have a straightforward Netbeans project, which contains a .java file that makes use of some annotations, which are handled by the Netbeans annotation processor (org.openide.filesystems.annotations.LayerGeneratingProcessor to be precise) to create a .xml file during compilation.
All of this worked fine up until today, when I accidentally forgot to add the dependency for the annotation processor to my new project (i.e. core/org-openide-filesystems.jar). Without that dependency being present I witnessed the strangest behavior: a build (via Netbeans as well as directly via ant on the commandline) would report to be successful, yet no .class files were generated at all.
What really threw me off was that the build call come back with a success. Not a single warning or other indicator that something was amiss.. just no classes generated and a tiny little .jar file that only contained the Bundle.properties files, but again no .class files.
The workaround
So much for the scenario itself. After a while I eventually came to find out about a javac option that would lead the compiler to finally tell me that something went wrong: -XDdev. I have never seen this option before and from my googling all I could find was that these kind of options are referred to as Hidden Options. But I haven't found a good listing of what hidden options are available and what they're good for. Any reference on that would be much appreciated.
Anyways, adding this option to the compile, the actual javac call would spit out a large stacktrace that eventually boils down to a ClassNotFoundException for the LayerGeneratorProcessor class. Lo and behold, once I added the dependency for that class to the project everything builds fine again.
The remaining problem
What is funny (as in scary) is that even despite this exception being printed to stderr and indicating that annotation processing failed, the overall javac call succeeds! It still comes back with build successful and acts as if everything was fine. Without the -XDdev option, one would not even have any indication at all from the output that something went wrong.
Finally, my actual question: is there some way to turn this behavior into a proper error? While -XDdev is fine to find out the problem, it requires you to look at the build output, which especially in a CI context will not be feasible. I would like to protect others and myself from accidentally forgetting the dependency in the future by somehow switching this behavior to a proper build error such that we are also notified by the CI system in those cases.
I am using eclipse helio with java.
The watch expression option is not working for me when debugging my code
If I am doing a watch on variable, I cant see the value of that variable in the watch view
if i hoover with my mouse over the variable in the code i can see its value
if I check the variable in the variables view I can see its value
but in the watch expressions window i cant see its value (and its a problem if i try to watch expressions for example)
did anyone encounter this problem
(it used to work fine and show values but then suddenly it stopped and i have no idea why)
thanks
For me the problem had to do with a bad source path configuration for the project. There's a bunch of different ways to fix this, but one is to right-click on the thread while paused in the debugger, select "Edit Source Lookup...", and fiddle around with the paths specified there (see below).
In my case the problem was that I had specified the source lookup path as a "File System Directory". I was able to get my Expressions view working again by removing the "File System Directory" path and adding the source lookup as a "Java Project" instead.
You can check whether the problem is your source lookup path by opening the Debug -> Display view, and trying to evaluate a Java expression there. If you see a message like this, then your source lookup path is bad:
To perform an evaluation, an expression must be compiled in the context of a Java project's build path. The current execution context is not associated with a Java project in the workspace.
Typically (at least for simple cases) the expression view works. But sometimes it indeed stops showing the values.
Usually refresh and clean of project + (sometimes) restart of eclipse help.
If you are able to see simple values and cannot see expression it sometimes because the class that is returned by expression does not appear in import list of current class. In this case I often try to write explicit cast to class into the watch expression and sometimes it helps.
Good luck.
In my case, while debugging against wildfly, my workspace somehow got corrupted after I opened as a maven project the sources of eclipselink 2.6.4.
After having open this maven project - that has all sort of dependencies you can image on oracle libraries - within my workspace the expressions and display view simply did not work any more. The variables view, while debugging continue to work as well as all the mouse overs.
I then created a fresh new empty worksapace.
Imported only the project I wanted to debug.
Reconfigured wildfly server.
And voila, expressions and display were back to work.
So, I have no idea what what happened to my eclipse... but it appears to be related to the metadata in my workspace being fundamentally broken.
Therefore, if you get the feeling that out of the blue lose the ability to properly debug in your workspace, it might be that your worksapce got hammered.
This appears to be what has happened to me. Finally, I am now back to being able to use the expressions on this new workspace.
This may seem a weird Q.
I had written a code in Java (in Eclipse). Then, I did some modifications to the code. Now, I am trying to run the new code (modified), but it is still giving me the output which it was giving for the previous code.
I have put few debug points in the code, but it is skipping some of the debug points (though it should stop at them) and stopping at some debug point, but even here it is calling the methods which were present in previous code at that location (though I have commented them now). It seems from somewhere it is still debugging the old code.
How to get rid of it?
Thanks!
Have you tried cleaning the project?
Project(menu) -> clean
Also make sure
Project(menu) -> Build Automatically
is selected so that all new code you write is compiled then and there
If the clean and build doesn't work, it's possible that there is a jar file contains the class you edited, so the eclipse will run the compiled class file in the jar instead of your current file.
There are two possibilities because of which the java code is not updating properly:
Project -> Build Automatically is not checked
In .project file of Project org.eclipse.jdt.core.javabuilder build command is commented or missing. Here the below mentioned piece of code should not be commented:
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments></arguments>
</buildCommand>
I had the same issue. I cleared out some code in Eclipse that printed to the console but these changes weren't reflected when I ran the code from command line. I am creating and executing a jar file from my code. Turns out I forgot to recompile after I made changes. So the following resolved the issues:
javac packageName/*.java
Now when I create my jar file, it will reflect the changes.
I've run into this issue lately - new code stops working. I click clean - then it can't find the main class anymore and the program won't run at all.
The fix I've found (works every time) is refactor - rename the project. This instantly fixes it. Then I just change the name back. Then after a couple days it happens again and I have to rename it again to fix it.
I am trying to trouble shoot a JUnit. In the source code, I have set break point in two places: 1) in a line where a static member is initialized 2) the first line of one of the test cases.
The debugger stops in the static field initializing line. But it doesn't stop in the test case. No matter where I set the break point in the test case, the debugger doesn't stop there. I know for sure that the test case is executed as I can see the log messages that I have added appear in the log.
Any help would be greatly appreciated.
I am using Eclipse Galileo and JUnit4 launcher.
Fix could be as simple as clicking run/skip all breakpoints. Worked for me.
Make sure, under Run > Debug Configurations, that 'Stop in main' is selected, if applicable to your situation.
This could be related to one of the bugs in JDK 6 Update 14, as indicated in the release notes for JDK 6 update 15.
If this indeed turns out to be the issue, you should move to a higher version of the JDK (that's no guarantee though, since fixes have been released against 6u16, 6u18 and 7b1). The best bet is to use -XX:+UseParallelGC flag. Increasing the size of the minimum and maximum heap size, to delay the first GC, bring temporary relief.
By the way, use this bug report in Eclipse to track how others have been faring.
You might have accidentally skipped all break points in Eclipse toolbar. To fix this go to Eclipse -> Run -> Skip All Breakpoints.
Usually when this happens to me (rare but it does) means that the code being executed is different than the code in the editor. It will happen from time to time for Eclipse that the built classes and the code in editor are out of sync. When that happens I get all sort of weird debugger behavior (debugging empty lines, skipping lines of code etc).
Restarting Eclipse, clean all projects and rebuild everything usually clears things up. I had also the Maven plugins (older versions... had not had it for a while now) that had a tendency to do that too.
Otherwise it might be a bug, maybe the one Vineet stated,
Hope this helps
In my case the problem was that I hadn't Debug view open in Debug perspective, so:
1 - Be sure you have debug perspective opened:
2 - Be sure you have debug view opened:
Project -> Clean seemed to work for me on on JRE 8
In order to debugger work with remote, the java .class files must be complied along with debugging information. If "-g:none" option was passed to compiler then the class file will not have necessary information and hence debugger will not be able to match breakpoints on source code with that class in remote. Meanwhile, if jars/class files were obfuscated, then they also will not have any debug info. According to your responses, most probably this is not your case, but this info could be useful for others who face the same issue.
Remove all breakpoints and re-add them.
For JDK7, run->Debug Configurations, check "Keep JUnit running after a test run when debugging".
Happened to me once, when I had unchecked "Run > Build automatically" and forgot to re-check it.
Make sure you declare the package at the top.
In my groovy code this stops at breakpoints:
package Pkg1
import java.awt.event.ItemEvent;
isMule = false
class LineItem {
// Structure defining individual DB rows
public String ACCOUNT_CODE
public String ACCOUNT_DESC
...
This does not stop at breakpoints:
import java.awt.event.ItemEvent;
isMule = false
class LineItem {
// Structure defining individual DB rows
public String ACCOUNT_CODE
public String ACCOUNT_DESC
...
To remove the breakpoints:
Debug your class as a junit test
When your debugger stops, click the "breakpoints" tab next to "variables" and "expressions"
At the top right of the breakpoint tab, click the button with two 'X'
Stop the test, replace your breakpoint and run the debugger again
Also verify if breakpoints on other lines DO work, it may be a bug in the debugger. I have had a problem with the Eclipse debugger where putting a breakpoint on a boolean assignment whose code was on the next line didn't work I reported this here, but putting it on the previous or next line did.
If nothing works-
Remove that Remote/Local Debug Configuration, and Create a new One.
Add the Source in Debug Configurations.
Another possible problem is that the debugger port may be blocked by the firewall. For example, I was using mule anypoint studio (v 5.4.3). The default debugger port is 6666. When a flow is executed, it would not stop at breakpoint. when I changed the port to another (e.g. 8099), it worked fine.
Go to Right click->Debug Configuration and check if too many debug instances are created.
My issue was resolved when i deleted multiple debug instances from configuration and freshly started debugging.
If you are on Eclipse,
Right click on your project folder under "Package Explorer".
Goto Source -> Clean up and choose your project.
This will cleanup any mess and your break-point should work now.
Creating a new workspace worked for me.
In my case I had multiple projects in same workspace. The java file I was trying to debug was present in more than one projects with same package.
I didn't need the other project, so simply closed unrelated projects (or remove the file from unrelated project).
One additional comment regarding Vineet Reynolds answer.
I found out that I had to set -XX:+UseParallelGC in eclipse.ini
I setup the virtual machine (vm) arguments as follows
-vmargs
-Dosgi.requiredJavaVersion=1.7
-Xms512m
-Xmx1024m
-XX:+UseParallelGC
-XX:PermSize=256M
-XX:MaxPermSize=512M
that solved the issue.
It happened to me when I had several project, I realized that I created a spring boot configuration of a project B from a project A (I clicked on Duplicate and change the parameter to have a config for the project B) and in that case I haven't the debug mode so I removed this config and I created directly a new one by clicking New in Spring Boot App
This is what works for me:
I had to put my local server address in the PHP Server configuration like this:
Note: that address, is the one I configure in my Apache .conf file.
Note: the only breakpoint that was working was the 'Break at first line', after that, the breakpoints didn't work.
Note: check your xdebug properties in your php.ini file, and remove any you think is not required.