我也遇到过这个问题。我正在使用一个蚂蚁构建脚本。我正在开发一个遗留应用程序，所以我使用的是jdk版本1.4.2。这个方法曾经有用，所以我开始四处寻找。我注意到在JRE选项卡上的Debug配置下，Java的版本被设置为1.7。一旦我把它改回1.4，它就工作了。

我希望这能有所帮助。

我试图调试日志管理器，需要将jre更改为jdk，然后在“主”选项卡中选择这个jdk，调试配置的“Java运行时环境”|“运行时jre”，然后一切正常。

如果您确实指出了您正在使用的eclipse版本和技术(例如，Java JDT，或面向Java的AJDT，或c++ CDT)，这将有所帮助。

在Java方面，我猜想您的“勾选编译器选项中的复选框”指的就是这个

在“窗口—>首选项—> Java—>编译器—>类文件生成”下，所有“类文件”生成选项都设置为True:

(1)添加可变属性， (2) addline number， (3)添加源文件名， (4)保存未使用的局部变量。

您的项目是否只在全局级别(windows Preferences)或在项目特定级别检查这些?

你确定打开的类(你试图在上面设置断点):

是您的源代码之一(并且不是来自第三方库) 是。java，而不是。class?

尝试清理所有内容并重新构建所有内容，检查潜在的jar冲突。

在编译/构建jar时，我做了上面列出的所有事情-仍然有同样的问题。

最终，在启动服务器时，下面列出的jvmarg更改最终为我工作:

删除/注释了一堆与javaagent和bootclasspath相关的jvm参数。

<!-- jvmarg value=“${agentfile}” /-->

< !贾维德- lib /雷丁——>

<!-- jvmarg value=“-Xbootclasspath/a：/foo /-->

打开/取消注释以下行:

<jvmarg value= -Xdebug />

然后，当我启动服务器时，我就可以到达断点了。我怀疑javaagent在某种程度上干扰了Eclipse检测行号的能力。

我的情况与此类似:

我正在调试一个JUnit测试 我使用Mockito创建一个间谍，如在spyTask =间谍(new Task()) 我将断点放在我正在监视的类中(在Task.java中)

这个断点会生成问题中的错误，每次我运行Debug As…> JUnit测试

为了解决这个问题，我将断点“向上”移动到实际测试中(在TaskTest.java内部)。一旦执行停止，我将断点添加回原来的位置(在Task.java中)。

我仍然得到相同的错误，但点击“确定”后，断点工作正常。

希望这对大家有所帮助，

-gmale

这里有详细的解释:

https://github.com/spring-projects/spring-ide/issues/78

只是为了将来参考，这是答案的相关部分(忽略引用Spring Boot应用程序的事实，在许多其他情况下行为是相同的):

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".