Eclipse - невозможно установить точку останова из-за отсутствующих атрибутов номера строки

Я получаю эту странную ошибку в Eclipse при попытке установить точку останова.

Unable to insert breakpoint Absent Line Number Information

Я установил флажок в параметрах компилятора, но не повезло.

У меня было то же сообщение об ошибке в Eclipse 3.4.1, SUN JVM1.6.0_07, подключенный к Tomcat 6.0 (работает в режиме отладки на другом компьютере, Sun JVM1.6.0_16, отладочное соединение работало правильно).

Окно -> Настройки -> Java -> Компилятор -> Генерация файла класса: проверено «добавить атрибуты номера строки в созданный файл класса» . Я сделал чистую, перекомпилировать. Я снял галочку, перекомпилировал, проверил, перекомпилировал. Я убедился, что проект использует глобальные настройки. Все то же сообщение.

Я перешел на сборку муравья, используя

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

Тем не менее, то же сообщение.

Я не выяснил, что вызвало это сообщение и почему оно не исчезло. Хотя казалось, что это как-то связано с запущенным сеансом отладки Tomcat: при отключении перекомпиляция решает проблему. Но при подключении отладчика к Tomcat или при установке новых точек останова во время подключенного сеанса отладки он появился снова.

Однако оказалось, что сообщение было неверным : я действительно смог отладить и установить точки останова, как до, так и во время отладки ( javap -l также показывал номера строк). Так что просто игнорируй это :)

1. В меню затмения, перейдите в Window-> Preferences-> Java-> Compiler
2. Снимите флажок «Добавить атрибуты номера строки ...»
3. Нажмите Применить -> Да
4. Установите флажок «Добавить атрибут номера строки ...»
5. Применить снова.
6. Счастливой отладки

Это исправило мою проблему:

1. Окно -> Настройки -> Сервер -> Среды выполнения
2. Apache Tomcat -> редактировать
3. Выберите JDK вместо JRE

Для проблем, связанных с Spring, учтите, что в некоторых случаях он генерирует классы «без номеров строк»; например@Service аннотированный класс без интерфейса, добавьте интерфейс, и вы сможете отлаживать. Смотрите здесь для полного примера.

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

Служба выше будет иметь интерфейс, сгенерированный пружиной, вызывающей «пропущенные номера строк». Добавление реального интерфейса решает проблему генерации:

public interface TestService {
    void doSomething();
}

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

У меня есть ответ на эту проблему со стороны BlackBerry SDK: по какой-то причине, независимо от того, сколько раз я менял параметры в компиляторе, фактический базовый файл настроек не менялся.

Найдите в папке .settings вашего проекта файл с именем org.eclipse.jdt.core.prefs .

Там вы можете изменить настройки вручную:

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

редактировать: в дополнение к этому, я заметил, что иногда я могу игнорировать предупреждение, которое дает Eclipse, и оно все равно остановится в нужном месте ... curioser и curioser ... Я положил это в корзину вещей, с которыми мы учимся иметь дело при работе в качестве разработчика

Это сработало для меня:

1. Под Window --> Preferences --> Java --> Compiler --> Classfile Generationвсе варианты должны бытьTrue .
2. Сделано debug="true"в build.xml<javac> задаче .
3. Разверните приложение в коте войной, созданной муравьем
4. Перезапустил Tomcat в Debugрежиме

Не знаю, если это все еще актуально, возможно, другой моряк сочтет это полезным.

Сообщение появляется, когда файл класса скомпилирован, флаги отладки отключены.

В затмении вы можете включить его с помощью вышеупомянутых опций,

Окно -> Настройки -> Java -> Компилятор -> Генерация файла класса: «добавить атрибуты номера строки в сгенерированный файл класса»

Но если у вас есть JAR-файл, вы получите скомпилированный вывод. Нет простого способа решить эту проблему.

Если у вас есть доступ к источнику и вы используете ant для получения файла jar, вы можете изменить задачу ant следующим образом.

  <javac  destdir="${build.destDir}" srcdir="${build.srcDir}" source="1.6" fork="true" target="${javac.target}" debug="on" debuglevel="lines,vars,source" deprecation="on" memoryInitialSize="512m" memoryMaximumSize="1024m" optimize="true"   >

Удачной отладки ..

ссылка: http://doc.sumy.ua/prog/Java/javanut/ch16_04.htm

Я попробовал почти все решения здесь и не повезло. Вы пытались нажать «Не говори мне больше»? После этого я перезапустил свою программу, и все было хорошо. Затмение достигло моей точки останова, как будто ничего не случилось.

Основной причиной для меня было то, что Eclipse пытался настроить отладку для автоматически сгенерированных прокси-объектов Spring CGLIB. Если вам не нужно что-то отлаживать на этом уровне, вы должны игнорировать проблему.

Было бы полезно, если бы вы указали версию затмения, которую вы используете, и технологию (например, Java JDT или AJDT для Aspect Java или C ++ CDT).

На стороне Java, я полагаю, что ваш «галочка в опциях компилятора» относится к этому

Под " Window --> Preferences --> Java --> Compiler --> Classfile Generation" все Class fileпараметры генерации 'установлены на True:

• (1) добавить переменные атрибуты,
• (2) номера addline,
• (3) добавить имя исходного файла,
• (4) сохранить неиспользованные локальные переменные.

Ваш проект проверен только на глобальном уровне (настройки Windows) или на уровне проекта?

И уверены ли вы, что класс открыт (на котором вы пытаетесь установить точку останова):

• является одним из ваших источников (а не из сторонней библиотеки)
• это .java, а не .class?

Попытайтесь очистить все и восстановить все, проверьте на возможные конфликты фляги .

У меня была эта проблема при попытке запустить Tomcat в режиме отладки из Eclipse. У меня был файл сборки ANT, заботящийся о компиляции и развертывании. После установки флага отладки в true (как упоминалось в других ответах) и повторного развертывания приложения оно работало нормально:

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

ПРИМЕЧАНИЕ: если вы только что добавили флаг отладки и перекомпилировали, вам все равно нужно повторно развернуть ваше приложение на сервере, поскольку именно здесь Eclipse отлаживает файлы классов. Совершенно очевидно, но легко потратить час или около того, почесывая голову и удивляясь, почему это не работает (поверьте мне).

попробуйте изменить используемый jreвами. Вместо этого установите jreв папке JDK.

Поскольку у меня установлено 6 разных версий Java, мне пришлось изменить соответствие JDK по умолчанию, чтобы оно соответствовало той версии Java, которую я хотел использовать. В Eclipse по умолчанию уровень соответствия компилятора был установлен на Java 1.7, когда все было собрано / скомпилировано с использованием Java 1.6.

Так что все, что я сделал, было

1. В меню затмения, перейдите в Window-> Preferences-> Java-> Compiler
2. Под JDK Compliance я изменил уровень соответствия компилятора с 1,7 на 1,6

Теперь Eclipse больше не жалуется на «Невозможно вставить информацию об отсутствующей строке номера точки останова», а точки отладки фактически работают !!!

Если больше ничего не работает, откройте перспективу отладки, очистите все существующие точки останова и затем установите их снова.

Это подробно объясняется здесь:

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

Просто для дальнейшего использования, это важная часть ответа (не обращайте внимания на тот факт, что относится к приложению Spring Boot, поведение такое же для многих других случаев):

Всякий раз, когда вы устанавливаете точку останова в Eclipse / STS, IDE пытается установить точку останова в виртуальной машине, если вы запускаете приложение. Это то, что происходит в вашем случае, когда вы запускаете загрузочное приложение в режиме отладки.

Для каждого класса, загружаемого в JVM, среда IDE проверяет, нужно ли ей устанавливать точку останова или нет. Если он решает установить точку останова, он пытается это сделать (используя информацию из определения точки останова в IDE, включая ее номер строки, поскольку обычно вы устанавливаете точки останова строки в исходном файле в данной строке).

Это решение (устанавливать ли точку останова для данного загруженного класса или нет) проверяет типы, для которых вы устанавливаете точку останова, включающие типы и внутренние классы. Это гарантирует, что точки останова для внутренних классов (даже анонимных внутренних классов) установлены в JVM (и не игнорируются).

Spring Boot генерирует внутренний класс для вашего контроллера во время выполнения (это сгенерированный CGLIB внутренний класс, который появляется в сообщении об ошибке). Когда JVM загружает этот класс, он пытается установить точку останова номера строки вмещающего типа (для этого внутреннего класса). Поскольку сгенерированный внутренний класс не имеет никакой информации о номере строки (ему не нужно иметь информацию о номере строки), установка точки останова завершается неудачно для этого внутреннего класса с упомянутым сообщением об ошибке.

Когда среда IDE загружает тип включения (сам класс вашего контроллера), она также пытается установить точку останова на линии и преуспевает с этим. Это визуализируется с помощью контрольного маркера на маркере точки останова.

Поэтому вы можете смело игнорировать появившееся сообщение об ошибке. Чтобы это сообщение об ошибке не отображалось, вы можете перейти к настройкам (Java -> Debug) и отключить «Предупреждать, когда не удается установить точку останова из-за отсутствующих атрибутов номера строки».

Моя ситуация была похожа:

• Я отлаживал тест JUnit
• Я использовал Mockito для создания шпиона, как в spyTask = spy(new Task())
• Я поставил точку останова внутри класса, за которым я шпионил (внутри Task.java)

Эта точка останова генерирует соответствующую ошибку каждый раз, когда я запускаю Debug As... > JUnit Test

Чтобы решить проблему, я переместил точку останова «вверх» в реальный тест (внутри TaskTest.java). После того, как выполнение остановилось, я добавил точку останова туда, где она была у меня изначально (внутри Task.java).

Я все еще получил ту же ошибку, но после нажатия «ОК», точка останова работала очень хорошо.

Надеюсь, это поможет кому-то,

-gmale

У меня была такая же проблема, когда я делал на сервере Jetty и компилировал новый файл .war от ANT. Вы должны сделать ту же версию компилятора jdk / jre и путь сборки (например, jdk 1.6v33, jdk 1.7, ....) после того, как вы установите Java Compiler, как было написано ранее.

Я сделал все и до сих пор не работает. Решением было удалить скомпилированные файлы .class и цель сгенерированного файла war, и теперь он работает :)

Получил это сообщение с Spring AOP (похоже, из библиотеки CGLIB). Нажав Игнорировать, кажется, работает нормально, я все еще могу отладить.

Я нашел еще одну причину для этого сообщения. Я программировал Scala. Решение было:

1. Открыть Run -> Отладка конфигурации
2. В нижней части вкладки «Main», рядом с кнопками «Apply» и «Revert», находится текст, указывающий, какой Launcher вы используете, а рядом с ним есть гиперссылка «Select other». Это странный элемент пользовательского интерфейса, на первый взгляд не очень действенный.
3. Используйте ссылку «Выбрать другое» и выберите «Средство запуска приложения Scala (новый отладчик)». Другой, похоже, не работает со Scala.

Теперь отладка должна работать. Обратите внимание, что я установил плагин Scala IDE, эта опция может быть недоступна, если у вас ее нет.

Все вышеперечисленное не работает для меня. Ниже решения наконец-то сработали. Конфигурации отладки -> Classpath -> Записи пользователя -> (Добавьте папку src проекта, который вы хотите отладить.)

У меня была такая же проблема при отладке WAR (созданного из нескольких артефактов проекта Eclipse), развернутого в Tomcat.

Я строю все, используя скрипт сборки ANT. Если это то, что вы делаете, убедитесь, что флаг debug = true установлен на каждой вашей задаче javac ant. Это была моя единственная проблема - надеюсь, это поможет вашей проблеме!

У меня была такая же ошибка с JBoss 7.1 .. И я сделал то же самое, что и Zefiro. Просто проигнорировал ошибку, и я смог нормально установить точки останова. В моем случае я строил мыслительный муравей, и это моя задача javac:

<javac
        srcdir="${src.dir}"
        destdir="${build.classes.dir}" 
        includeantruntime="false" 
        debug="${debug}"
        verbose="false"
        debuglevel="lines,vars,source"
        source="1.6"
        target="1.6">

        <!-- Sppressing warning for setting an older source without bootclasspath
             (see: https://blogs.oracle.com/darcy/entry/bootclasspath_older_source) -->
        <compilerarg value="-Xlint:-options"/>

        <classpath>
            <fileset dir="${lib.dir}" includes="*.jar" />
            <fileset dir="${jboss.lib.dir}" includes="**/*.jar" />
        </classpath>

    </javac>

У меня возникла та же проблема, я потратил много времени на поиск решения, но эти решения бесполезны, поэтому я сам изучаю все случаи, и в конце концов я обнаружил, что проблема заключается в конфликте между версиями JDK. Ниже приведены шаги для решения проблемы: 1. Удалите все версии JDK и JRE, оставьте только одну версию. 2. Установить систему JAVA_HOME и компилятор java в Eclipse одинаково. В некоторых случаях приведенная выше ошибка не исчезнет, ​​но мы сможем запустить модель отладки.

Как только я столкнулся с той же ошибкой при использовании junit и Mockito, я забыл добавить @PrepareForTest статический класс.

Добавьте ниже код исправил мою проблему.

@PrepareForTest({XXXXX.class})

_{Не уверен, что это был тот же случай.}

Моя проблема заключалась в том, что у меня было 2 JAR, и я пытался переопределить один из них другим в зависимости от их порядка на Java Build Path => Order & Exportвкладке в Eclipse, потому что один был для отладки, а другой - нет (отладочный JAR был первым в порядке). Когда я делал это таким образом, мне приходилось вручную подключать источник.

Я попытался удалить JAR без отладки и поместить JAR отладки в мой каталог \ WEB-INF \ lib \, очистка, сборка и т. Д., И это сработало. На этот раз (удалив подключенный источник), он автоматически позволил бы мне перемещаться по коду отладки без необходимости подключения какого-либо источника вручную. Точки останова и отладки тоже работали.

Если у кого-то все еще есть проблемы, я также попробовал все эти конкретные решения, упомянутые в других ответах:

• Снимите флажок, примените и перепроверьте Add line number attributes...
• Редактирование вручную, org.eclipse.jdt.core.prefsкак указано в другом ответе: https://stackoverflow.com/a/31588700/1599699
• Гарантирование того, что JAR генерировался с включенной отладкой.
• Изменение уровня соответствия JDK с 1.6 до 1.7 (таким образом, соответствует JDK, который я использовал).

Я также сделал обычное завершение работы сервера (и убедившись, что java.exe действительно закрыт ...), удалив каталоги \ build \ в обоих проектах, перезапустив Eclipse с параметром -clean, воссоздав JAR отладки, обновив, очистка и сборка проекта с JAR-файлом отладки, запуск сервера в режиме отладки, публикация / очистка и определение точек останова.

Я сделал все, что перечислено выше, во время компиляции / сборки jar-файлов - все еще была та же проблема.

В конце концов, изменения jvmarg, перечисленные ниже, при запуске сервера, наконец-то, сработали для меня:

1) Удалено / прокомментировано несколько аргументов jvm, относящихся к javaagent и bootclasspath.

2) Включил / не прокомментировал следующую строку:

Затем, когда я запускаю сервер, я могу достичь своих точек останова. Я подозреваю, что javaagent каким-то образом мешал Eclipse обнаруживать номера строк.

Проверьте / сделайте следующее:

1) В разделе «Окно -> Настройки -> Java -> Компилятор -> Генерация файлов классов» все параметры должны иметь значение True:

(1) Add variable attributes...
(2) Add line number attributes...
(3) Add source file name...
(4) Preserve unused (never read) local variables

2) В папке .settings вашего проекта найдите файл с именем org.eclipse.jdt.core.prefs. Проверьте или установите org.eclipse.jdt.core.compiler.debug.lineNumber = generate

3) Если окно ошибки все еще появляется, установите флажок, чтобы не отображать сообщение об ошибке.

4) Очистить и построить проект. Начните отладку.

Обычно окно ошибки больше не отображается, и информация об отладке отображается правильно.

Я столкнулся с этой проблемой также. Я использую скрипт сборки муравья. Я работаю над устаревшим приложением, поэтому использую jdk версии 1.4.2. Раньше это работало, поэтому я начал осматриваться. Я заметил, что в конфигурации Debug на вкладке JRE версия Java была установлена ​​на 1.7. Как только я изменил его обратно на 1.4, он работал.

Надеюсь, это поможет.

Я пытался отладить менеджер журналов и мне нужно было изменить jre на jdk, а затем выбрать этот jdk на вкладке «main», «Java Runtime Environment» | «runtime JRE» отладочной конфигурации тогда все было хорошо.

Я увидел эту проблему, когда аннотировал класс с помощью @ManagedBean (javax.annotation.ManagedBean). При запуске недавно выполненного приложения на JBoss EAP 6.2.0 появилось предупреждение. Игнорирование и запуск в любом случае не помогли - точка останова не была достигнута.

Я вызывал этот бин, используя EL на странице JSF. Теперь ... возможно, что @ManagedBean не годится для этого (я новичок в CDI). Когда я изменил свою аннотацию на @Model, мой компонент был выполнен, но предупреждение о точке останова также исчезло, и я достиг точки останова, как и ожидалось.

Подводя итог, можно сказать, что аннотация @ManagedBean испортила номера строк независимо от того, была ли эта аннотация неправильной.

Убедитесь, что проект, в котором основным классом среды выполнения является тот же проект, в котором находится класс, в котором вы имеете точки останова . Если нет, убедитесь, что оба проекта находятся в пути к классам конфигурации запуска и отображаются перед любыми jar-файлами и папками классов.