What's 'Breakpoint is invalid: Source code changed'?

Use IDEA version 4.5.3 #2250 to debug some java source,every time IDEA complain 'Breakpoint is invalid: Source code changed' and can't break.
In fact I didn't change any source code and just add some breakpoint.

16 comments

I'm getting this as well; regardless of compiling, the debugger won't stop at any breakpoint anywhere. The breakpoint X's out and says "Source code changed".

I've tried cleaning, recompiling, touching the binary files prior to running.

I've created a new project, which solved the problem, but the problem resurfaced after a week.

0

I used to get that also. It was caused by two things:

1) I used ant to compile my source externally
2) I had a module that mapped some (compiled by ant) classes from another module as a library.

When I fixed this, and let IDEA compile my classes whenever I build the smaller module that depended on the larger module, everything worked fine again.

0

I'm having a similar problem, same version/build of Idea. In my case I am compiling my project with Idea, but using an Ant script to make a JAR file and to deploy that JAR (along with everything else under the WEB-INF directory) to a remote Tomcat instance. Breakpoints all get this error, but oddly enough the error indication only shows up after I execute the code in which the breakpoint is set -- before, the IDE shows no error on the breakpoint. With this same project I used to deploy with a WAR file, and at that time the breakpoints worked fine.

This is driving me crazy (short drive ]]>). Any ideas at all would be greatly appreciated...

0

Seems to be a bad bug in 4.5.3. Our team of developers all experience the dreadded 'Breakpoint is invalid: Source code changed' message using Tomcat 5/JDK 1.5. We use Idea to compile all of our classes - we do start with Jars after getting a clean build but Idea rebuilds all of our classes so I am not sure why Idea gets mixed up.

The only work around we have found is to rebuild the module. Delete it, close Idea, start Idea, add the module again. Due to this bug and other issues with configuration, we add in an additional 5-10% overhead for all of our developers to the project plan for the task "Idea related work arounds and configuration".

Another bad bug casues us to mark both build war and build explode directory on the J2ee tab. You have to check build war to get Idea to deploy the web module after creating a new module. Once deployed you can then uncheck build war and continue to use only exploded directory. But remember to delete the temporary war (not the exploded dir) so Tomcat Idea don't waste time looking at it. Once you delete the war, you will find the next bug where Idea complains the war is missing, even though you just unchecked build war. Restart Idea and all will be fine.

"Tom Dilatush" <no_mail@jetbrains.com> wrote in message news:<32062735.1106519563896.JavaMail.itn@is.intellij.net>...

I'm having a similar problem, same version/build of Idea. In my case I am compiling my project with Idea, but using an Ant script to make a JAR file and to deploy that JAR (along with everything else under the WEB-INF directory) to a remote Tomcat instance. Breakpoints all get this error, but oddly enough the error indication only shows up after I execute the code in which the breakpoint is set -- before, the IDE shows no error on the breakpoint. With this same project I used to deploy with a WAR file, and at that time the breakpoints worked fine.

This is driving me crazy (short drive <smile>). Any ideas at all would be greatly appreciated...

0

This problem persisted until:
1. I checked again that the corresponding code is really deplayed on server
2. Replaced all compiled jars as libraries for other modules with inter-module dependencies

0

Hi,

I am getting the same problem: I tried all the solutions mentioned previously (compiled with Idea instead of ANT, closed my appserver -tomcat- + Idea, deleted all the build files, etc ...), and the result is totally unpredictable: it will randomly allow me to debug, but most of the time, despite my breakpoint initially looking valid, I get the dreaded red cross telling me that my source code has changed.

Please someone help ! I waste about 50% more time on not being able to debug my code, and I'm now seriously thinking of switching to another IDE, as, despite the fact I really like Idea, debugging is an essential tool I cannot do without.

Any help will be incredibly appreciated !!

Nick

PS: I use v4.5.4, build 2253

0

One of the previous posts was a little vague, but here's what worked for me:

  • File-&gt;Settings, open up the Modules section and click on the Libraries (Classpath) tab

  • Go through all of your libraries, and make sure that the source code in question is not in a jar that it is any of your libraries. I repeat, the compiled class cannot be in a jar that is inside of a library.


I didn't even have to restart IDEA. I simply unset and then reset my breakpoint (it changed to a checkmark this time), and then rehit my tomcat page and it worked.

I'm using IDEA 5.0, although hopefully that doesn't make a difference.

Ryan Shillington

0

Version 5.0 has this problem too

0

Ryan,

That was it ! As you said, the key is to never reference in the classpath your compiled code. That did the trick and it now works all the time :)

Many thanks,

Nick

0

This worked for me.
Idea 4.5.3. I just removed all the jars that had classes for which there were source files in my module.

0

Make sure that debug option of javac task was set as "true" in case if your jars were build using ANT.

By default ANT's javac strips out debug info and it makes impossible to use debug tool.

0

I am wondering if "the compiled class cannot be in a jar that is inside of a library" then why it would work for a while until something got changed ?
My case is like this, I modify and compile a Java source file and then put the compiled class to to a jar file(in module's classpath) with the following ANT script.

]]>
<include name="*/.class"/>
</fileset>
</jar>
</target>

then set a breakpoint to debug the new code, I found the debugger will stop at the breakpoint without any problem - even re-run it many time (without modifying source code) still see no problem.
But when I modify the source code again and run the same ANT script to update the jar file, then the debugger won't stop at the breakpoint any more - "Breakpoint is invalid: Source code changed".
So if the compiled class cannot be in a jar, then why the first modifying of source code(then inject in to a jar) work and all the subsequent modifying fail ?

Thanks
David

0

Could this have anything to do with IDEA running in a 1.4.x JVM while the application that it is accessing is in a 1.5.x JVM?

I consistantly get this problem in 4.5.4 (2253) along with EXTREMELY slow debugging data return times.

I am running a 64-bit 1.5 JDK (06) for the project (from Sun, not a third party one like Blackdown or anything) and I believe that IDEA is running on a 32-bit 1.4.2 JRE. It feels as though the two problems are somewhat related in the fact that I started noticing problems when my project switched to using 1.5.

0

I had the same problem. Part of the project had generating jars coming from a project module. The main project had these jars on it's class path. When I removed the generated jar files from the main project's classpath, the breakpoints worked correctly.

0

I have the same problem, been apparently randomly cropping up over the last year or so since I started using IDEA. It's apparently working ok at the moment (setup with no dependencies, all building done through ant and sub-component classes deployed as jars not the class files).

One thing I did notice/realize is that IDEA caches multiple versions of the jars you use - I'm now routinely clearing out the ones I build to try and avoid problems in the future, but it's too early to tell. For reference the cache dir is typically something like:

C:\Documents and Settings\]]>\.IntelliJIdea\system\caches

0

Quick addendum: it isn't just the jars that IDEA caches, it's the compiled classes for modules as well. I guess this may well be where the inconsistencies creep in... With this in mind, when I hit this problem I'm clearing both the cached jars (e.g. util.jar.9bed00a1_) and also the corresponding cached classes (e.g. util.5045755e.d507b56d_803fed38) - looking good so far.

0

Please sign in to leave a comment.