4

Using Intellij (v14 and now v15) I have put breakpoints to debug no-yet released classes coming from an external dependency (usually a snapshot version) for a web app running in Tomcat 7+.

when I change that external dependency to a released version, recompile the project and run in debug mode; IntelliJ still halts the execution at the old class breakpoint even though the breakpoint no longer exists in the breakpoint list view (from menu: Run > Breakpoints).

I have tried the following:

  • Clean and rebuild all artifacts before launching the app to make sure the deployed apps have the updated dependencies.
  • Run the "Invalidated Caches / Restart" feature, which clear my beloved file change history but not these breakpoints.
  • Remove all breakpoints: (which clear the current valid breakpoints but not the phantom breakpoints since they are not in the current list)

The only thing that has worked for me, is to re-attach the exact old source jar (whenever possible) look for the affected class and remove the breakpoint from there.

Is there any less inconvenient way to clear these phantom breakpoints?

danielgpm
  • 1,609
  • 12
  • 26

2 Answers2

8

Disclaimer: This is perhaps best suited as a comment but does not fit the limited number of chars.

Nice catch! I never had this problem before but I managed to reproduce it by switching the JDK version. I simply opened java.io.File from JDK8 and set a breakpoint on line 276:

public File(String pathname) {
    if (pathname == null) { // <= breakpoint here
        throw new NullPointerException();
    }
    this.path = fs.normalize(pathname);
    this.prefixLength = fs.prefixLength(this.path);
}

Then I switched to JDK6 which has a simple right-curly-bracket ( } ) on that line. However, when pressing CTRL+SHIFT+F8 (windows) the breakpoint IS available, but has the description of the old source file:

breakpoints

This got me thinking, so I tried to figure out where the breakpoints are stored, and it turns out they're in <project root>/.idea/workspace.xml under the <component name="XDebuggerManager"> section:

<component name="XDebuggerManager">
    <breakpoint-manager>
      <breakpoints>
        ...
        <line-breakpoint enabled="true" type="java-line">
          <url>jar://C:/Program Files/Java/jdk1.8.0_45/src.zip!/java/io/File.java</url>
          <line>275</line>
          <properties />
          <option name="timeStamp" value="4" />
        </line-breakpoint>
      </breakpoints>
      ...

So it looks like it keeps a reference to the initial file. I'm not sure whether the breakpoints would still appear in the list when you're using maven, gradle, etc, case in which it would be easy to reference the path to your old jar from the local repo, but at this point I don't think it matters anyway.

Quick workaround (maybe?!): Nonetheless, if you manually remove the phantom breakpoint from the xml and save the file, IJ will automatically pick up the change, and update the setting. At the minimum after doing it, the breakpoint no longer appeared in my list.

A quick search on their tracker revealed this issue affecting v14.1.1 (I'm currently on 14.1.6) which seems to not be fixed yet, so I guess we'll just have to wait until it gets fixed (somehow, because right now I can't think of a simple/decent way).

Morfic
  • 15,178
  • 3
  • 51
  • 61
  • Thank you, you answer helped to understand how this works a little better. I noticed that intellij save different entries depending on the source type: If you put the breakpoint on a decompiled class, the breakpoint will be for the ClassName.class, whereas it will be for `ClassName.java` if you attach/download the actual source code. – danielgpm Feb 24 '16 at 15:50
  • @danielgpm No problem. Did you get the chance to see if they still trigger during execution if you remove them from the xml? – Morfic Feb 24 '16 at 16:04
  • No, when I clear all the entries for the class they don't trigger anymore – danielgpm Feb 29 '16 at 15:28
  • 2
    Cool thanks, I edited `workspace.xml` and removed the ` – HankCa Apr 24 '19 at 01:59
  • Closing the IDE (in my case PhpStorm) and editing workspace.xml worked for me too. No cache invalidation needed. I suspect the phantom breakpoint occurred when the code where my breakpoint was, was changed by composer. Thanks all! – marcvangend Oct 18 '21 at 11:50
0

If you have multiple applications linked to each other. It will help to redeploy the "CORRECT" application to your server. That was the case with me. Check that the correct war file is deployed to your server.

user957129
  • 43
  • 1
  • 2