Eclipse is not stopping/breaking at breakpoint? - java

I am trying to put breakpoints in my code for some simple debugging but my program is not stopping or telling me if the breakpoints is reached. I use CRTL+SHIFT+B and the breakpoint is visible in blue (enabled) on the left side. I am using these breakpoints in my core project and running from desktop project. Am i missing something and/or how to fix this?

Did you check the
Menu -> Run -> Skip All Breakpoints
to see if it was checked? I ran into this once and it drove me crazy as well.

Related

Eclipse Debugger Not working. Weird breakpoint

I have been using Eclipse for a while now, and up to about a week ago the debugger has been working fine. However, now it does not run in the debug mode, but as if I just pressed run. Also, my breakpoints look different and have small black arrows on them. I tried reinstalled eclipse, but that did not work. This is what the breakpoints look like now. I am using jdk 1.8.0_172.
These are some of the breakpoints:
These are Triggers for breakpoints.
For details:
See Eclipse 4.7 - New and Noteworthy
Watch my short video

IntelliJ IDEA: Breakpoint not being hit, and is shown without the tick, just a red dot

I have a gradle project, and when I put a breakpoint it is displayed as a red dot, with a tick inside, and it just works fine.
The problem is that in some classes (in the same project, not a dependency class), the red dot doesn't have a tick inside, and it doesn't tell why it wouldn't work. And it just doesn't work..:
What have I tried so far:
Gradle clean & build
Rebuild project
Restart debug
Invalidate caches and restart IntelliJ
Update IntelliJ to the latest version (2017.2.5)
Mute & Unmute breakpoints
This question is similar, but clearly not the same: Intellij IDEA: Breakpoint not being hit, and is shown greyed out
Did some searching through IntelliJ Help PDF:
Help Doc pg. 431
Their documentation Describes the checkmark as "Shown at run-time when the breakpoint is
recognized by the debugger as set on an
executable code line."
and the regular red dot as "Shown at design-time or during the debugging
session when the class with such breakpoint is
not yet loaded.
"
So it would seem that the line you're adding the breaking point to never gets executed. You can try stepping up line by line through the class to make sure the class is not getting hung up somewhere.
I made a n00b mistake on the IDE. Instead of hitting the debug button, I thought it would work the same as visual studio or eclipse in that I'd have to use the run button, yet when I hit the debug button (That looks like an actual bug) my break-point hit just fine.
I get this same issue intermittently from time to time, I always run the latest version of IDEA. The break points are shown as red but without a tick inside them. Even after I rebuild or re-run in debug they do not get a tick, and they do not "work", i.e., the code continues. I resolve by restarting IDEA, then restarting the debugger/debug run config.
The same happened with me on Mac machine. I followed these steps and all worked fine:
Stop server.
Close all intellij projects.
Open only the specific intellij project on which my application needs to run.
Start the server in debug mode.
I fixed this by manually deleting all build-related files (for some reason Rebuild did nothing) by running this command at the project's root folder. Note that it does also remove Intellij's temporary configuration files, that are usually not included in git repositories anyway. Replace MODULE with the subfolder containing the module for the project. If you are building an Android app with Android Studio the main module name is usually app.
rm -rf ./local.properties ./.gradle/ ./.idea/ ./MODULE/build/ ./MODULE/out/
Then restart Intellij with the File -> Invalidate Caches / Restart option, wait for the build and indexing to finish, and debugging should start working again.
Rebuild solved my problem.
clean & rebuild
Invalidates caches/restart if necessary
I had the same issue in my mac, tried restarting server, machine, invalidate caches and nothing helped. Then, I noticed when the server is started in debug mode, i didnt see this message:
Connected to the target VM, address: '127.0.0.1:64197', transport: 'socket' and I realized that there could be some problem with the server as such.
Solution:
Created new server using command line "./server create " and then associated this server for run configuration. Now started server in debug mode and I saw above message connected to socket port and I am able to see the tick marks on debug point.
I was also facing this issue and found that my tomcat configuration was not right.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>compile</scope>
</dependency>
The scope tag had value as "provided". Changed it to compile and it worked fine.
Android app configuration was the problem for me. I had minifyEnabled true in debug section inside buildTypes in build.gradle file. I had to change it to minifyEnabled false. This change forced me to set multiDexEnabled true as it states in this post Android gives error "Cannot fit requested classes in a single dex file"
My issue got resolved by just updating the IntelliJ in IntelliJIdea -> Check for updates..
All,
This could be a common bug in the Intellij IDEA debugger instead use the key short cuts
like F8 and F9 etc during the debug steps for [ step over and run to debug next point etc..] and don't rely on the debug console buttons provided in the ide
For some reason we experienced this when we upgraded from java 11 to 17. The fix was to use a SpringBoot configuration and not a maven configuration for run/debug.
For me it was a port problem, I don't know why but I had to go back to port 8082 which I was using for tomcat.
This worked for me:
Make a note of the Java version in the run configuration tab (for me its JDK 9 or later)
Go to File -> Settings -> Search for Java compiler -> set Project Bycode version to the same version that you see in run config.
Stop and rerun debugging.
Run config image
Here is what I did.
My code was within an anonymous class where the
debug point would not get the tick mark.
I extracted the code to a
new instance method of the main container class. Then I was able to set
debug point in the new method.
As shown in the picture above.
You can check whether the breakpoint is disabled, the disabled breakpoint button will be grayed out there.

How to degug a standalone Java program in Eclipse using Maven?

I am a beginner with Java, Maven, and Eclipse.
I have made a simple standalone Java program and generated a Maven package with Eclipse LUNA. When I began to debug the Java program, I found that breakpoints did not work. When setting the breakpoint, there will be a circle at the beginning of code line.
Now there was circle, but it had a line over the circle.
How can I execute debugging the Java program with Maven in Eclipse?
Do it like this:
a.Right click project.Then, Debug as -> Maven build ...
b.In the goals field put -Dmaven.surefire.debug test
c.In the parameters put a new parameter called forkMode with a value of never
Set your breakpoints down and run this configuration and it should hit the breakpoint.
If you are really saying "line over circle" then you have breakpoints there in eclipse and disabled.
Go to "Debug" view > Breakpoints and enable you should stop at your breakpoints then in your debug session

Debugging Gradle build files in Intellij / Android Studio

I am sometimes running into obscure problems with Gradle. Sometimes it helps if i am reading the source files or adding println statements to figure out what i can do and what the state is.
But i would really like to just place a breakpoint and list the internal state of variables. is that possible using Android Studio or IntelliJ ?
I would also love to ctrl-click to the DSL keywords so i can get some context.
Just placing a breakpoint and clicking "debug" from the list of gradle tasks does not work, it just runs the tasks without stopping.
You can't debug Gradle files. We may someday implement this, as it would obviously be a great thing, but it's a long ways off. We're in the process of adding more intelligence about syntax highlighting and analysis of build files. Well, actually, JetBrains is adding it to IntelliJ and we're picking it up. This will get better over the coming weeks and months.
Original source
1. Create a debugger
Run -> Edit Configurations
Add New Configuration
Add Remote configuration
2. Open debug mode
$ export GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
3. Start debugger
$ ./gradlew someTask -Dorg.gradle.daemon=false #!important, disable daemon mode
4. Attach debugger
Set breakpoints
Start debug
5. Disable debug mode
$ unset GRADLE_OPTS

Debugging with Eclipse using multiple windows

I usually run a dual-monitor setup, so I have two Eclipse windows open for the same workspace, displaying different files. When I'm debugging and a breakpoint is hit, Eclipse switches to the "Debug" perspective, but it also shows the file/line where the breakpoint is in both of my windows. This occurs even if the file containing the breakpoint was open in one window but not the other (before the breakpoint was hit).
This is really annoying.
How can I have Eclipse only show the file containing the breakpoint in one window? Ideally, it would choose which window based on where the file is open already. If it's not already open somewhere, I don't really care which window it pops up in.
You can create another workspace and in that workspace create a new project from the same src code (same files in file system) of the one in your current project in your current workspace.
That would let you stop on one breakpoint without the other window stopping their too.
Notice that after you make some code modifications in one project you'd have to refresh the other project for those changes to apply in it.
Eclipse switches to the debug perspective for all windows the debug perspective has been opened once (i.e. the little icon on the right top corner is available). If you close that perspective (switch to another perspective is not sufficient), it won't switch to it anymore on that window.
At least, that's the behaviour I observed on Kepler (I know, that question is older but just came across, maybe it still helps someone).
This worked for me:
In Window->Preferences->Run/Debug->Launching->Launch Configurations enable "Apply window working set(s)"
Personally I find this more efficient than creating two workspaces.
Closing the Debug perspective (righ-click on the little icon on the right top corner) worked for me.
I'm using Oxygen and I have the following settings in the Run/Debug Preferences:
Open the associated perspective when launching: Never
Open the associated perspective when an application suspends: Prompt
Maybe you select the sources for Debugging by "File System Directory" instead of by "Java Project". To change this go to Run=>Debug Configuration=>Add Sources=Button: ADD...=>Java Project and select your Projects.
Make sure, that the added sources are found first by moving them to the top.
To disable multiple debugging in multiple windows in eclipse, go to Windows > Preferences > Run/Debug and uncheck Activate the debug view when a breakpoint is hit

Categories