Why does IntelliJ debugger skip lines when debugging?

Question

I am trying to switch to over to IntelliJ but when I load up my projects the debugger appear to be skipping lines and not tracking the actual source when I try to step through. I know this is a vague problem but does anyone know about issues that cause IntelliJ to link improperly to source code when debugging?

Answer 1

I am working on a project that has multiple modules. The test class in module B is used to run a test, during which code found in module A is invoked. My problem was that when I added new code to a class in module A, and I tried to debug the new code, the debugger would instead use a .class file, and my changes were ignored by the debugger. I tried many things, but it turned out to be a rather simple resolution. First, I went to File > Project Structure > Project Settings > Modules. In the list of modules, I selected module B. Then I selected the Dependencies tab. There is a list of dependencies in this tab. In order for the test class in module B to see the class under test in module A, I had to click the plus sign (+), to add a new dependency to the list. A list of modules and submodules were shown. I selected the submodule in module A that contained the class I wanted to debug, and I clicked ok. Now the submodule that I selected was shown in the dependencies list. I moved this submodule to just below where it says "module source", then I clicked apply and ok to close the Project Settings. When I reran the debugger, now the test in module B could "see" the code changes in module A, and after the debug action did a rebuild, I could proceed to debug as normal.

Answer 2

In my case, breakpoint/debugger wasn't working for Foo.java only. Turns out Foo.java was mocked in my test (@MockBean).

Answer 3

I fetched same problem. You can follow bellow steps:

1. Delete Build/Target folder
2. Close project from file and
3. Open project from Recent projects.
4. Debug again. Now debugger will hit your debug pointer location

Thanks :)

Answer 4

This problem could be similar to this issue https://intellij-support.jetbrains.com/hc/en-us/community/posts/206170749-IDEA-14-1-1-debugger-using-decompiled-code-instead-of-source-code.

In Project Structure (Ctrl+Alt+Shift+S) > Modules, if you have added any jar of the debugged module to any another module's dependencies, Intellij might use the decompiled version of that jar instead of the latest source code, so the execution will pause at a breakpoint in the decompiled version instead. This problem can occur even when the debugged module is called from other modules that do not depend on the debugged one.

To solve this, simply remove the jar of the debugged module from all modules' dependencies in the Project Structure. If you do not know which modules have the debugged module jar as dependencies, you can use some tools (Eg. Sublime Text, bash, ...) to search for the module name which is stored in Intellij *.iml file in each module. Once removing, you may need to Sync the project and do Maven > Reimport.

Answer 5

I've been fighting with a similar issue with a Gradle-based project. I have tried every combination of File -> Synchronize, Build -> Clean project, gradle clean build, etc. Deleted the .gradle cache. Decompiled the .class file and it looked like the correct version.

Ultimately, I just ended up removing all the build and out directories in the project, tried running the test again and finally picked up the current source version.

I remember in Eclipse I always had to deal with the Eclipse Dance. I guess this is IntelliJ's version of that.

UPDATE: I've found this to be a randomly recurring issue so I created an alias to do the deletes if you're running a Bash-equivalent. Just set the alias in your .bashrc or .zshrc and run deletebuilds within your project directory:

alias deletebuilds='find . | egrep "\.class$" | sed -e "s/\/build\/.*/\/build\//" | sort | uniq | xargs rm -rf'

This assumes your compiled class files are going into a build directory. Modify the sed part if they're going somewhere else.

Answer 6

You can configure IntelliJ to use the Eclipse java compiler, which may solve your issue. From the below link:

https://youtrack.jetbrains.com/issue/IDEA-8021

" This is not the first report about well-known old javac problem: for some try/catch and if/else structures it generates several bytecode instructions, which are wrongly associated with line numbers. So when stepping, debugger encounters jump instruction with the different line number and decides to stop at it (because the line number has changed). The javac shouldn't have assigned the different line number to that instruction.

You see different behaviour in Eclipse only because it uses its own compiler which is free from this problem. You'll see exactly the described behavour if you configure Eclipse to use javac for compilation. Alternatively, you can set IDEA to use eclipse compiler to workaround the problem (applicable only to current EAP version - builds 5xxx - which has integration with eclipse compiler)"

Also see this Q regarding configuring Maven to use the Eclipse compiler:

Using Eclipse Java Compiler (ecj) in maven builds

Answer 7

The only thing I can think of is that the current compiled classes don't match the Source you're using to debug. What happens in this circumstances is that IntelliJ (or any other IDE), gets the debug information from the classes, regarding things like line numbers, and then maps it to the current source you're viewing, to show you what code is being executed.

If the code is outdated, or the versions (the source code and the compiled class) mismatch in any way, it can happen that the debugged is giving the IDE information to show a certain line, but that information is not correct giving the current source code, which might cause what appears to be the debugged "jumping" lines or simply stopping in places that don't make much sense.

Have you rebuilt your project? Are those sources from classes in a Jar, and are you sure the versions match?

Hope it helps!