Zaćmienie - nie można zainstalować punktu przerwania z powodu brakujących atrybutów numeru linii

Podczas próby ustawienia punktu przerwania pojawia się ten dziwny błąd w środowisku Eclipse.

Unable to insert breakpoint Absent Line Number Information

Zaznaczyłem pole wyboru w opcjach kompilatora, ale bez powodzenia.

Miałem ten sam komunikat o błędzie w Eclipse 3.4.1, SUN JVM1.6.0_07 podłączony do Tomcat 6.0 (działający w trybie debugowania na innym komputerze, Sun JVM1.6.0_16, połączenie debugowania działało poprawnie).

Okno -> Preferencje -> Java -> Kompilator -> Generowanie pliku klas: zaznaczono „dodaj atrybuty numeru linii do wygenerowanego pliku klasy” . Zrobiłem czysty, ponownie skompilowałem. Usunąłem zaznaczenie, ponownie skompilowałem, sprawdziłem, ponownie skompilowałem. Upewniłem się, że projekt korzysta z ustawień globalnych. Wciąż ta sama wiadomość.

Za pomocą przełączyłem się na kompilację mrówek

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

Wciąż ta sama wiadomość.

Nie dowiedziałem się, co spowodowało ten komunikat i dlaczego nie zniknie. Chociaż wydawało się, że ma to coś wspólnego z uruchomioną sesją debugowania Tomcat: po rozłączeniu rekompilacja rozwiązuje problem. Ale po podłączeniu debugera do Tomcat lub ustawieniu nowych punktów przerwania podczas połączonej sesji debugowania pojawił się ponownie.

Okazało się jednak, że komunikat był niepoprawny : rzeczywiście byłem w stanie debugować i ustawiać punkty przerwania, zarówno przed debugowaniem, jak i podczas debugowania ( javap -l również pokazywał numery linii). Więc zignoruj ​​to :)

1. W menu Eclipse przejdź do Window-> Preferencje-> Java-> Kompilator
2. Odznacz pole wyboru „Dodaj atrybuty numeru linii ...”
3. Kliknij Zastosuj -> Tak
4. Zaznacz pole wyboru „Dodaj atrybut numeru linii ...”
5. Zastosuj ponownie.
6. Udanego debugowania

To naprawiło mój problem:

1. Okno -> preferencje -> serwer -> środowiska wykonawcze
2. Apache Tomcat -> edycja
3. Wybierz JDK zamiast JRE

W przypadku problemów związanych z wiosną należy wziąć pod uwagę, że w niektórych przypadkach generuje klasy „bez numerów linii”; na przykład @Serviceklasa z adnotacjami bez interfejsu, dodaj interfejs i możesz debugować. zobacz tutaj pełny przykład.

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

Powyższa usługa będzie miała interfejs generowany przez wiosnę powodujący „brakujące numery linii”. Dodanie prawdziwego interfejsu rozwiązuje problem z generowaniem:

public interface TestService {
    void doSomething();
}

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

Mam odpowiedź na ten problem od strony BlackBerry SDK rzeczy: Z jakiegoś powodu, bez względu na to, ile razy zmieniałem opcje w kompilatorze, rzeczywisty plik ustawień podstawowych nie zmienił się.

Zajrzyj do folderu .settings swojego projektu, aby zobaczyć plik o nazwie org.eclipse.jdt.core.prefs .

Tam możesz ręcznie zmodyfikować ustawienia:

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

edytuj: Ponadto zauważyłem, że czasami mogę zignorować ostrzeżenie, które daje Eclipse, i nadal zatrzyma się w wymaganym miejscu ... kurier i kurator ... Wrzucam to do koszyka rzeczy, z którymi uczymy się radzić sobie podczas pracy jako programista

To działało dla mnie:

1. Poniżej Window --> Preferences --> Java --> Compiler --> Classfile Generationwszystkie opcje muszą być True.
2. Wykonane debug="true"w <javac>zadaniu build.xml .
3. Wdróż aplikację w kocurze podczas wojny wygenerowanej przez mrówkę
4. Uruchomiłem ponownie Tomcat w Debugtrybie

Nie wiem, czy to nadal jest istotne, być może inny żeglarz uzna to za przydatne.

Komunikat pojawia się, gdy skompilowano plik klasy, flagi debugowania są wyłączone.

W Eclipse możesz włączyć tę funkcję, korzystając z wyżej wymienionych opcji,

Okno -> Preferencje -> Java -> Kompilator -> Generowanie pliku klas: „dodaj atrybuty numeru linii do wygenerowanego pliku klasy”

Ale jeśli masz plik jar, otrzymasz skompilowane dane wyjściowe. Nie ma łatwego sposobu na rozwiązanie tego problemu.

Jeśli masz dostęp do źródła i używasz mrówki, aby uzyskać plik jar, możesz zmodyfikować zadanie mrówki w następujący sposób.

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

Miłego debugowania ...

ref: http://doc.sumy.ua/prog/Java/javanut/ch16_04.htm

Próbowałem tutaj prawie każdego rozwiązania i bez powodzenia. Czy próbowałeś kliknąć „Nie mów mi więcej”? Po tym zrestartowałem program i wszystko poszło dobrze. Zaćmienie uderzyło w mój punkt przerwania, jakby nic się nie stało.

Główną przyczyną dla mnie było to, że Eclipse próbował skonfigurować debugowanie dla automatycznie generowanych obiektów proxy CGLIB Spring. O ile nie musisz debugować czegoś na tym poziomie, zignoruj ​​problem.

Byłoby pomocne, gdybyś wskazał używaną wersję zaćmienia i technologię (Java JDT lub AJDT dla Aspect Java lub C ++ CDT), dla pewności.

Po stronie Java, przypuszczam, że odnosi się do tego „Zaznaczone pole wyboru z opcji kompilatora”

W obszarze „ Window --> Preferences --> Java --> Compiler --> Classfile Generation” wszystkie Class fileopcje generowania są ustawione na True:

• (1) dodaj zmienne atrybuty,
• (2) numery dodatków,
• (3) dodaj nazwę pliku źródłowego,
• (4) zachowaj nieużywane zmienne lokalne.

Czy twój projekt ma sprawdzane tylko na poziomie globalnym (Preferencje systemu Windows) czy na poziomie konkretnego projektu?

I czy jesteś pewien, że klasa się otworzyła (na której próbujesz ustawić punkt przerwania):

• jest jednym z twoich źródeł (i nie pochodzi z biblioteki innej firmy)
• jest a .javanie .class?

Spróbuj wyczyścić wszystko i odbudować wszystko, sprawdź potencjalne konflikty słoików .

Miałem ten problem podczas próby uruchomienia Tomcata w trybie debugowania z Eclipse. Miałem plik kompilacji ANT zajmujący się kompilacją i wdrażaniem. Po ustawieniu flagi debugowania na wartość true (jak wspomniano w innych odpowiedziach) i ponownym wdrożeniu aplikacji działała poprawnie:

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

UWAGA: jeśli właśnie dodałeś flagę debugowania i dokonałeś ponownej kompilacji, nadal musisz ponownie wdrożyć aplikację na serwerze, ponieważ w tym miejscu Eclipse debuguje pliki klas. To bardzo oczywiste, ale łatwo spędzić godzinę, drapiąc się w głowę i zastanawiając się, dlaczego to nie działa (zaufaj mi).

spróbuj zmienić jreużywany. Ustaw zamiast tego jrew folderze JDK.

Ponieważ mam zainstalowanych 6 różnych wersji Java, musiałem zmienić domyślną zgodność JDK, aby była zgodna z wersją Java, której chciałem używać. Domyślnie Eclipse miał ustawiony poziom zgodności kompilatora na Java 1.7, gdy wszystko zostało zbudowane / skompilowane przy użyciu Java 1.6.

Więc wszystko co zrobiłem było

1. W menu Eclipse przejdź do Window-> Preferencje-> Java-> Kompilator
2. Pod JDK Compliance zmieniłem poziom zgodności kompilatora z 1,7 na 1,6

Teraz Eclipse nie narzeka już na „Nie można wstawić punktu przerwania Brak informacji o numerze linii”, a punkty przerwania debugowania faktycznie działają !!!

Jeśli nic innego nie działa, otwórz perspektywę debugowania, wyczyść wszystkie istniejące punkty przerwania, a następnie ustaw je ponownie.

Wyjaśnia to szczegółowo tutaj:

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

Tylko na przyszłość, jest to odpowiednia część odpowiedzi (zignoruj ​​fakt, że odnosi się do aplikacji Spring Boot, zachowanie jest takie samo w wielu innych przypadkach):

Ilekroć ustawiasz punkt przerwania w Eclipse / STS, IDE próbuje ustawić punkt przerwania na maszynie wirtualnej, jeśli uruchomisz aplikację. Tak dzieje się w twoim przypadku, gdy uruchomisz aplikację rozruchową w trybie debugowania.

Dla każdej klasy ładowanej do JVM IDE sprawdza, czy musi ustawić punkt przerwania, czy nie. Jeśli zdecyduje się ustawić punkt przerwania, spróbuje to zrobić (wykorzystując informacje z definicji punktu przerwania w IDE, w tym jego numer linii, ponieważ zwykle ustawiasz punkty przerwania w pliku źródłowym w danej linii).

Ta decyzja (czy ustawić punkt przerwania dla danej załadowanej klasy, czy nie) sprawdza typy, dla których ustawiono punkt przerwania, obejmując typy i klasy wewnętrzne. Dzięki temu punkty przerwania dla klas wewnętrznych (nawet anonimowych klas wewnętrznych) są ustawione na JVM (i nie są ignorowane).

Spring Boot generuje wewnętrzną klasę dla kontrolera w czasie wykonywania (jest to klasa wewnętrzna wygenerowana przez CGLIB, która pojawia się w komunikacie o błędzie). Gdy JVM ładuje tę klasę, próbuje ustawić punkt przerwania numeru linii typu otaczającego (dla tej klasy wewnętrznej). Ponieważ wygenerowana klasa wewnętrzna nie ma żadnych informacji o numerze linii (nie musi mieć informacji o numerze linii), ustawienie punktu przerwania dla tej klasy wewnętrznej nie powiedzie się ze wspomnianym komunikatem o błędzie.

Kiedy IDE ładuje typ zamykający (sama klasa kontrolera), próbuje również ustawić punkt przerwania linii i to się udaje. Jest to wizualizowane za pomocą znacznika wyboru na znaczniku punktu przerwania.

Dlatego możesz bezpiecznie zignorować wyświetlony komunikat o błędzie. Aby uniknąć wyświetlania tego komunikatu o błędzie, możesz przejść do preferencji (Java -> Debugowanie) i wyłączyć opcję „Ostrzegaj, gdy nie można zainstalować punktu przerwania z powodu brakujących atrybutów numeru linii”.

Moja sytuacja była podobna:

• Debugowałem test JUnit
• Użyłem Mockito do stworzenia szpiega, jak w spyTask = spy(new Task())
• Umieściłem punkt przerwania w klasie, którą szpiegowałem (wewnątrz Task.java)

Ten punkt przerwania generuje dany błąd przy każdym uruchomieniu Debug As... > JUnit Test

Aby rozwiązać problem, przeniosłem punkt przerwania „w górę” do właściwego testu (wewnątrz TaskTest.java). Po zakończeniu wykonywania dodałem punkt przerwania z powrotem tam, gdzie go miałem, pierwotnie (wewnątrz Task.java).

Nadal dostaję ten sam błąd, ale po kliknięciu „OK” punkt przerwania zadziałał dobrze.

Mam nadzieję, że komuś pomoże

-gomale

Miałem ten sam problem, kiedy robiłem na serwerze jetty i kompilowałem nowy plik .war przez ANT. Powinieneś stworzyć tę samą wersję kompilatora jdk / jre i ścieżkę kompilacji (na przykład jdk 1.6v33, jdk 1.7, ....) po ustawieniu kompilatora Java tak, jak napisano wcześniej.

Zrobiłem wszystko i nadal nie działa. Rozwiązaniem było usunięcie skompilowanych plików .class i celu wygenerowanego pliku wojny, a teraz działa :)

Dostałem ten komunikat z Spring AOP (wydaje się, że pochodzi z biblioteki CGLIB). Kliknięcie opcji Ignoruj ​​wydaje się działać poprawnie, nadal mogę debugować.

Znalazłem kolejny powód tej wiadomości. Programowałem Scalę. Rozwiązaniem było:

1. Otwórz Uruchom -> Konfiguracje debugowania
2. W zakładce głównej na dole, obok przycisków „Zastosuj” i „Cofnij”, znajduje się tekst informujący, którego programu uruchamiającego używasz, a obok niego link „Wybierz inny”. To dziwny element interfejsu użytkownika, na pierwszy rzut oka nie wydaje się możliwy do wykonania.
3. Użyj linku „Wybierz inny” i wybierz „Program uruchamiający aplikację Scala (nowy debugger)”. Drugi wydaje się nie współpracować ze Scalą.

Teraz debugowanie powinno działać. Zauważ, że zainstalowałem wtyczkę Scala IDE, ta opcja może być niedostępna, jeśli jej nie masz.

Przede wszystkim nie działało dla mnie. Poniższe rozwiązania w końcu zadziałały. Konfiguracje debugowania -> Ścieżka klasy -> Wpisy użytkownika -> (Dodaj folder src projektu, który chcesz debugować.)

Miałem ten sam problem podczas debugowania WAR (zbudowanej z wielu artefaktów projektu Eclipse) wdrożonej w Tomcat.

Buduję wszystko za pomocą skryptu kompilacji ANT. Jeśli to właśnie robisz, upewnij się, że flaga debug = true jest ustawiona dla każdego zadania javac ant. To był mój jedyny problem - mam nadzieję, że to pomoże w twoim problemie!

Miałem ten sam błąd z JBoss 7.1. I zrobiłem to samo co Zefiro. Zignorowałem błąd i udało mi się normalnie ustawić punkty przerwania. W moim przypadku budowałem narzędzie do budowania mrówek i oto moje zadanie 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>

Mam ten sam problem, spędziłem dużo czasu na szukaniu rozwiązania, ale te rozwiązania są bezużyteczne, więc sam studiuję wszystkie przypadki, w końcu znalazłem problem, to jest konflikt między wersjami JDK. Poniżej przedstawiono kroki rozwiązania problemu: 1. Usuń wszystkie wersje JDK i JRE, zachowaj tylko jedną wersję. 2. Ustaw system JAVA_HOME, a kompilator Java w Eclipse jest taki sam. W niektórych przypadkach powyższy błąd nie zniknie, ale będziemy mogli uruchomić model debugowania.

Gdy napotkałem ten sam błąd, gdy korzystałem z junit i Mockito, zapomniałem dodać @PrepareForTestdla klasy statycznej.

Dodaj poniższy kod naprawił mój problem.

@PrepareForTest({XXXXX.class})

_{Nie jestem pewien, czy to był ten sam przypadek.}

Mój problem polegał na tym, że miałem 2 pliki JAR i próbowałem zastąpić jeden z drugim na podstawie jego kolejności w Java Build Path => Order & Exportzakładce w Eclipse, ponieważ jeden był do debugowania, a drugi nie (pierwszy plik JAR debugowania był w kolejności). Kiedy zrobiłem to w ten sposób, musiałem ręcznie dołączyć źródło.

Próbowałem usunąć plik JAR niebędący debugowaniem i umieścić plik JAR debugowania w moim katalogu \ WEB-INF \ lib \, czyszczeniu, budowaniu itp. I działało. Tym razem (po usunięciu dołączonego źródła) automatycznie pozwoli mi to poruszać się po kodzie debugowania, bez konieczności ręcznego dołączania dowolnego źródła. Działa również Breakpoints i debugowanie.

W przypadku, gdy ktoś nadal ma problemy, wypróbowałem również wszystkie te rozwiązania wymienione w innych odpowiedziach:

• Odznacz, zastosuj i sprawdź ponownie Add line number attributes...
• Ręczna edycja, org.eclipse.jdt.core.prefsjak wspomniano w innej odpowiedzi: https://stackoverflow.com/a/31588700/1599699
• Upewnij się, że plik JAR był generowany przy włączonym debugowaniu.
• Zmiana poziomu zgodności JDK z 1.6 na 1.7 (tym samym dopasowując się do JDK, którego używałem).

Zrobiłem także zwykłe zamykanie serwera (i upewnienie się, że java.exe jest faktycznie zamknięty ...), usuwając katalogi \ build \ w obu projektach, ponownie uruchamiając Eclipse z parametrem -clean, odtwarzając JAR debugowania, odświeżając, czyszczenie i budowanie projektu przy użyciu pliku JAR debugowania, uruchamianie serwera w trybie debugowania, publikowanie / czyszczenie i przerywanie.

Zrobiłem wszystkie powyższe elementy podczas kompilacji / budowania słoików - wciąż miałem ten sam problem.

Ostatecznie zmiany jvmarg wymienione poniżej podczas uruchamiania serwera są tym, co w końcu działało dla mnie:

1) Usunąłem / skomentowałem kilka argumentów JVM dotyczących javaagent i bootclasspath.

2) Włączono / skomentowano następujący wiersz:

Potem, kiedy uruchamiam serwer, jestem w stanie trafić moje punkty przerwania. Podejrzewam, że javaagent w jakiś sposób zakłócał zdolność Eclipse do wykrywania numerów linii.

Sprawdź / wykonaj następujące czynności:

1) W „Oknie -> Preferencje -> Java -> Kompilator -> Generowanie pliku klas” wszystkie opcje muszą być zgodne z prawdą:

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

2) W folderze .settings swojego projektu poszukaj pliku o nazwie org.eclipse.jdt.core.prefs. Sprawdź lub ustaw org.eclipse.jdt.core.compiler.debug.lineNumber = generuj

3) Jeśli nadal pojawia się okno błędu, kliknij pole wyboru, aby nie wyświetlać komunikatu o błędzie.

4) Oczyść i zbuduj projekt. Rozpocznij debugowanie.

Zwykle okno błędu nie jest już wyświetlane, a informacje debugowania są wyświetlane poprawnie.

Wpadłem również na ten problem. Korzystam ze skryptu budowania mrówek. Pracuję nad starszą aplikacją, więc używam jdk w wersji 1.4.2. Kiedyś to działało, więc zacząłem się rozglądać. Zauważyłem, że w konfiguracji debugowania na karcie JRE wersja Java została ustawiona na 1.7. Po zmianie z powrotem na 1.4 działało.

Mam nadzieję, że to pomoże.

Próbowałem debugować menedżera rejestrowania i musiałem zmienić JRE na JDK, a następnie wybrać JDK na karcie „Main”, „Java Runtime Environment” | „środowisko uruchomieniowe JRE” konfiguracji debugowania było wtedy w porządku.

Widziałem ten problem, kiedy adnotowałem klasę za pomocą @ManagedBean (javax.annotation.ManagedBean). Komunikat ostrzegawczy pojawił się podczas uruchamiania nowo zgodnej aplikacji w JBoss EAP 6.2.0. Zignorowanie go i uruchomienie mimo wszystko nie pomogło - nigdy nie osiągnięto punktu przerwania.

Dzwoniłem do tej fasoli za pomocą EL na stronie JSF. Teraz ... możliwe, że @ManagedBean nie nadaje się do tego (jestem nowy w CDI). Kiedy zmieniłem adnotację na @Model, moja fasola została wykonana, ale ostrzeżenie o punkcie przerwania również zniknęło i osiągnąłem punkt przerwania zgodnie z oczekiwaniami.

Podsumowując, z pewnością wyglądało to tak, jakby adnotacja @ManagedBean pomieszała numery wierszy, niezależnie od tego, czy użyto niewłaściwej adnotacji.

Upewnij się, że projekt, w którym znajduje się główna klasa środowiska wykonawczego, jest tym samym projektem, w którym znajduje się klasa, w której znajdują się punkty przerwania . Jeśli nie, upewnij się, że oba projekty znajdują się w ścieżce klas konfiguracji uruchamiania i pojawiają się przed wszelkimi słoikami i folderami klas.