Unable to install breakpoint due to missing line number attributes

[ahmedjaad]

I have a simple Spring boot web app in Spring Tool Suite, i can run the app as a spring boot by alt+shift+X,B but when i try to debug by alt+shift+D,B,i get this error "Unable to install breakpoint due to missing line number attributes", i have tried all suggestions I've found here on stackoverflow, the issue is still there.

[martinlippert]

Can you please attach a sample project or point us towards a repo at Github that contains a sample project?

[wcomnisky]

I'm having the same problem but unfortunately I cannot share the code although it looks the same problem is happening on the project khoubyari/spring-boot-rest-example based on the issue #8.

Spring Tool Suite

Version: 3.8.4.RELEASE
Build Id: 201703310825
Platform: Eclipse Neon.3 (4.6.3)

OS

LSB Version:	core-9.20160110ubuntu5-amd64:core-9.20160110ubuntu5-noarch:security-9.20160110ubuntu5-amd64:security-9.20160110ubuntu5-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 16.10
Release:	16.10
Codename:	yakkety

Java

java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

[martinlippert]

The reason that this happen is because:

Whenever you set a breakpoint in Eclipse/STS, the IDE tries to set the breakpoint in the VM if you launch an app. That is what happens in your case when you run the boot app in debug mode.

For each class that gets loaded into the JVM, the IDE checks whether it needs to set a breakpoint or not. If it decides to set the breakpoint, the tries to do so (using the information from the breakpoint definition in the IDE, including its line number, since you usually set line breakpoints on a source file at a given line).

This decision (whether to set the breakpoint on a given loaded class or not) checks the types that you set the breakpoint on, enclosing types, and inner classes. This makes sure that breakpoints for inner classes (even anonymous inner classes) are set to the JVM (and are not ignored).

Spring Boot generates an inner class for your controller at runtime (this is the CGLIB generated inner class that appears in the error message). When the JVM loads that class, it tries to set the line number breakpoint of the enclosing type (for this inner class). Since the generated inner class doesn't have any line number information (it doesn't need to have line number information), setting the breakpoint fails for this inner class with the mentioned error message.

When the IDE loads the enclosing type (your controller class itself), it also tries to set the line breakpoint and succeeds with that. This is visualized with the check marker on the breakpoint marker.

Therefore you can safely ignore the error message that shows up. To avoid this error message to show up, you can go to the preferences (Java -> Debug) and disable "Warn when unable to install breakpoint due to missing line number attributes".

[martinlippert]

And thanks for pointing me to the other issue and the sample project, I was able to use that to debug into all the details here. Thanks again for that pointer, much appreciated!!!

[kdvolder]

Maybe we should reopen this ticket and look at overriding the default value of the preference as a proper resolution. That might avoid other people getting confused by this 'harmless' error they should just ignore.

[martinlippert]

I am not all in favor of setting too many config options by default for our users, so I am not sure about this one. Let people comment here if they think this option should be disabled by default for all our users and we can do that.

[N0stalgia]

why do you just ignore it and then successfully debug, I also did the same thing ,but it does not work

[kdvolder]

@N0stalgia The other people hitting this error get it because of a CGLib generated classes (the error message shows something with 'CGLib' in classname. Does your error message mention CGLib? If not then it is a different problem and simply ignoring the error may not work.

[N0stalgia]

yes, the error message mentioned CGLIB, and here is the message below.
last time , I went to the preferences (Java -> Debug) and disabled "Warn when unable to install breakpoint due to missing line number attributes" option, and the break point problem is still there.

I also checked the other setting of java compiler

what could go wrong

[martinlippert]

The compiler option to generate the line number attributes is unrelated to this, since the class that is referenced in that popup is generated in the fly by Spring and not compiled by the IDE.

However, the overall setting Java -> Debug -> Warn when unable to install breakpoint due to missing line number attributes should avoid that warning popup to appear. Can you double check?

If that doesn't work, I would recommend to attach a sample project that reproduces this problem, so that we can double check on our end, too. Thanks!!!

[kdvolder]

There is nothing wrong. The CGLib is just a proxy class generated by spring framework. It will never have line number information. The error popup is disturbing and misleading, but it can be safely ignored. The important point is... if you put a breakpoint in your controller class, and you do something that makes that code execute... does the debugger stop on that line? When I tried it... it does. So the error is just a bit scary and makes it seem like something is wrong, but in effect everything is working just fine.

[vincenthsin]

@martinlippert Thank you for solving my questions!

[goxr3plus]

@martinlippert I followed all the above , the popups dissapeared but the breakpoints are not working at all the project just executes like no breakpoints are present at all :( ....

[martinlippert]

@goxr3plus can you provide a sample project for us to re-evaluate the issue? Would like to reproduce this locally.

[goxr3plus]

Now everything works fine :)

…

On Fri, Dec 14, 2018, 10:37 Martin Lippert ***@***.*** wrote: @goxr3plus <https://github.com/goxr3plus> can you provide a sample project for us to re-evaluate the issue? Would like to reproduce this locally. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#78 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATbiwFge9t8FCtFfcNAhEHSQ6UjXHihaks5u42NLgaJpZM4KyUVJ> .

[martinlippert]

Glad to hear and thanks for letting us know.

[sw-enthusiast]

@goxr3plus I ran into the same problem, can u please explain the solution. Thanks!

[gaojiangood]

@goxr3plus I ran into the same problem, can u please explain the solution. Thanks!

me too.

[kdvolder]

can u please explain the solution

The solution is simple, just ignore the error. The breakpoints should work just fine. The reason for the error is something to do with proxy classes generated by spring framework. These classes do not have source code or line numbers associated with them. This is normal because the classes are generated directly in bytecode. As far as I can tell this an error that Eclipse shows you, but is not actually interferring with the ability of breakpoints in real source code. If you do have an example where you did set a breakpoin and that breakpoint does not work, then please provide this example and we can investigate it. Otherwise, my advice is just ignore the error.

[aanchal10]

Disabling the option solved my issue as well. Thank you

[JDSalcedo]

I just remove all my breakpoints and restart the app in debug mode, then I mark breakpoints again.

[ralphcook]

I don't know if you'll entertain another question about this, but it's worth a try. In your very thorough explanation, you have the following paragraph:

Spring Boot generates an inner class for your controller at runtime (this is the CGLIB generated inner class that appears in the error message). When the JVM loads that class, it tries to set the line number breakpoint of the enclosing type (for this inner class). Since the generated inner class doesn't have any line number information (it doesn't need to have line number information), setting the breakpoint fails for this inner class with the mentioned error message.

The thing I don't understand here is why anything is attempting to set a breakpoint on the inner class; alternately, why does it warn about not being able to set a breakpoint on the inner class when no breakpoint is indicated for it? There is a breakpoint configured for the enclosing class at a specific line number, why is the JVM attempting to set a breakpoint on lines in a class for which no breakpoint has been indicated by the user (or the IDE, or the code, or whatever).

I dislike disabling warnings on principle; this one is benign enough, but the general "Just ignore that warning" is something I treat with suspicion. Supposedly if it was not worth warning about no one would have bothered. There have been lots of times where warnings have indicated a problem that I otherwise might not have noticed, and some that pointed me to an error that would otherwise been harder to find.

[martinlippert]

The thing I don't understand here is why anything is attempting to set a breakpoint on the inner class; alternately, why does it warn about not being able to set a breakpoint on the inner class when no breakpoint is indicated for it? There is a breakpoint configured for the enclosing class at a specific line number, why is the JVM attempting to set a breakpoint on lines in a class for which no breakpoint has been indicated by the user (or the IDE, or the code, or whatever).

I understand what you mean and it is indeed a bit confusing from the users point of view. As far as I remember (my analysis of this is quite a while ago), the IDE doesn't analyze each breakpoint to guess whether it might be set on an inner class or not inside a file. You could raise a bug at Eclipse JDT for this and start a discussion over there. That team will probably know a lot more details of the internals than I do, so maybe worth doing that: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JDT

I dislike disabling warnings on principle; this one is benign enough, but the general "Just ignore that warning" is something I treat with suspicion. Supposedly if it was not worth warning about no one would have bothered. There have been lots of times where warnings have indicated a problem that I otherwise might not have noticed, and some that pointed me to an error that would otherwise been harder to find.

Yes, totally agree.

[Chealer]

It seems Spring has decided to disable the preference, since I do not get these warnings (as of STS 4.14.1). I guess the team decided in the end to override Eclipse, since Eclipse still generates spurious warnings as of 2022-03.