Eclipse - Unable to install breakpoint due to missing line number attributes

Question

I am getting this strange error in Eclipse while trying to set a breakpoint.

Unable to insert breakpoint Absent Line Number Information

I ticked the checkbox from Compiler options but no luck.

Solution 1

I had the same error message in Eclipse 3.4.1, SUN JVM1.6.0_07 connected to Tomcat 6.0 (running in debug-mode on a different machine, Sun JVM1.6.0_16, the debug connection did work correctly).

Window --> Preferences --> Java --> Compiler --> Classfile Generation: "add line number attributes to generated class file" was checked. I did a clean, recompile. I did uncheck it, recompile, check it, recompile. I made sure the project did use the global settings. Still the same message.

I switched to ant build, using

<javac srcdir="./src/java" destdir="./bin" debug="true">

Still, same message.

I didn't find out what caused this message and why it wouldn't go away. Though it seemed to have something to do with the running Tomcat debug session: when disconnected, recompiling solves the issue. But on connecting the debugger to Tomcat or on setting new breakpoints during a connected debug session, it appeared again.

However, it turned out the message was wrong: I was indeed able to debug and set breakpoints, both before and during debugging (javap -l did show line numbers, too). So just ignore it :)

Solution 2

This fixed my issue:

1. Window -> preferences -> server -> runtime environments
2. Apache Tomcat -> edit
3. Select a JDK instead of JRE

Solution 3

For Spring related issues consider that in some cases it generate classes "without line numbers"; for example a @Service annotated class without an interface, add the interface and you can debug. see here for a complete example.

@Service("SkillService")
public class TestServiceWithoutInterface {
   public void doSomething() {
      System.out.println("Hello TestServiceWithoutInterface");
   }
}

The service above will have an interface generated by spring causing "missing line numbers". Adding a real interface solve the generation problem:

public interface TestService {
    void doSomething();
}

@Service("SkillService")
public class TestServiceImpl implements TestService {
   public void doSomething() {
      System.out.println("Hello TestServiceImpl");
   }
}

Solution 4

I have the answer to this problem from the BlackBerry SDK side of things: For some reason, no matter how many times I changed the options in the compiler, the actual underlying settings file did not change.

Have a look in the .settings folder of your project for a file called org.eclipse.jdt.core.prefs.

In there you can modify the settings manually:

org.eclipse.jdt.core.compiler.debug.lineNumber=generate

edit: Further to this, I have noticed that sometimes I can ignore the alert Eclipse gives, and it will still stop at the required place... curioser and curioser... I put this into the bucket of things we learn to deal with when working as dev.

Solution 5

I tried almost every solution here and no luck. Did you try clicking "Don't tell me again"? After doing so I restarted my program and all was well. Eclipse hit my breakpoint as if nothing was wrong.

The root cause for me was Eclipse was trying to setup debugging for auto-generated Spring CGLIB proxy objects. Unless you need to debug something at that level you should ignore the issue.

View more solutions

Comments

[chandrajeet]

Hi VonC, I am on Eclpise Ganymede, Java 1.6 Yes I have the settings globally. I am trying to set it on my own Java code written, so yes I do have the .java & .class files. And I did a javap on that class. It generates the line numbers

[VonC]

@chandrajeet if you have those settings set globally, I supposed you checked your project does not override them with project specific settings ? If not, the only thing I see right now is to put breakpoints on .class instead of .java...

[Vik David]

The above didn't work for me. I had to click the 'Remove all Breakpoints' icon in the Eclipse > Breakpoints view, then re-add the breakpoints. That worked.

[Ali]

I closed all the other project, removed all breakpoints, made a random change in the file, cleaned the project, introduced the break point again. That worked for me

[Justin Skiles]

Adding debug="true" to the javac task of the ant build script worked.

[Paul]

This fixed my problem (had the wrong version of jdk specified in ant config). It did fix the problem, but eclipse STILL gave me the error message. So be sure to actually go through and try to debug your code after you make this change - don't let the error message put you off.

[Magnilex]

This answer is still valid for my installation of Eclipse Kepler running on windows 8 64 bit with Java 7.

[Bane]

"it turned out the message was wrong..." -- this should be ridiculously over-emphasized. Even after reading that, I didn't comprehend what it is that you were saying. Consider moving your entire answer to the bottom and at the top in big bold box say something like "It is likely that this message means nothing -- try just clicking the don't-bother-me-about-it and see if you can still debug".

[Admin]

I encountered this in Eclipse Luna working in a "spring-boot" app. After removing all breakpoints, and re-adding, the problem went away, but also I had built at least once with classfile line numbers off also, but according to Vik David's answer perhaps all that was required was deleting and re-adding the breakpoints.

[CamHart]

What does "add the interface" mean? Import it into the file?

[Heisenberg]

Nothing above worked for me. So I deleted my project, did mvn eclipse:eclipse and imported it again. Working fine now :D

[DaBlick]

If the problem is fixed by adding debug="true" than that's one problem: of course you can't set reliably breakpoints if you're compiling without debug information. My theory is that there's another problem having to do with setting a breakpoint in a class that is in some way proxied by Spring (instrumented via Spring AOP or whatever). I haven't diagnosed it yet, don't have a fix, but I think the problem is that the instrumented code hangs around too long. I suspect deleting the Tomcat temp directories may solve that, but I haven't tried that yet.

[malvadao]

I was facing the same problem, using Spring Boot and trying to debug a test class. Turns out I had not instantiated the class I was trying to inspect, and, therefore, it was accusing this error and throwing a NullPointerException. I'd also recommend checking if your variables are being instantiated correctly.

[ahmednabil88]

Even your app not web, solution is Ok, by make Installed JREs default is JDK instead of JRE

[Scala Enthusiast]

This will get you the debugging (at least it did for me) but be aware that it is debugging the version you have put in your path NOT the "Default" one which is what you have in your editor. You'll need to remove and re-add for any changes made in the editor to be reflected in the debugging.

[Poutrathor]

Hello the definitive explanation here github.com/spring-projects/spring-ide/issues/… and technology.first8.nl/…

[G_V]

I´m having this issue specifically within Lambda expressions used in code blocks like @Bean that are explicitly managed within Spring. Just checking "Don't show this message again" prevents the spam and the debugging works fine as far as I can tell. Weird.

[Titi]

This link has a solution stackoverflow.com/questions/20344230/…

[Alvargon]

I know the rule, but there are a lot of answers here. This one, works for me at Nov 2019 But I change the main Runtime enviorement too, that solve the problem 100%.

[Adam]

I have an @Configuration class and have this problem. But adding an interface doesn't help. Spring still generates one itself. I only have one public function on my class, which is @Override now (it's also @Bean, if that matters). I changed the class name to add "Impl" at the end and sue the original name for the interface. The message has changed to include the "Impl" but spring is still trying to generate it's own interface. is @Configuration special? Or the fact it's a bean function?