Eclipse - Não foi possível instalar o ponto de interrupção devido à falta de atributos de número de linha

Estou recebendo esse erro estranho no Eclipse ao tentar definir um ponto de interrupção.

Unable to insert breakpoint Absent Line Number Information

Marquei a caixa de seleção nas opções do compilador, mas sem sorte.

Eu tive a mesma mensagem de erro no Eclipse 3.4.1, SUN JVM1.6.0_07 conectado ao Tomcat 6.0 (executando no modo de depuração em uma máquina diferente, Sun JVM1.6.0_16, a conexão de depuração funcionou corretamente).

Janela -> Preferências -> Java -> Compilador -> Geração de arquivo de classe: "adicione atributos de número de linha ao arquivo de classe gerado" foi verificado. Eu fiz um limpo, recompile. Eu desmarquei, recompilei, verifiquei, recompilei. Garanti que o projeto usasse as configurações globais. Ainda a mesma mensagem.

Eu mudei para a construção de formigas, usando

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

Ainda assim, a mesma mensagem.

Não descobri o que causou essa mensagem e por que ela não desapareceu. Embora parecesse ter algo a ver com a sessão de depuração do Tomcat em execução: quando desconectada, a recompilação resolve o problema. Mas, ao conectar o depurador ao Tomcat ou ao definir novos pontos de interrupção durante uma sessão de depuração conectada, ele apareceu novamente.

No entanto, a mensagem estava errada : eu era capaz de depurar e definir pontos de interrupção, antes e durante a depuração (o javap -l também mostrava os números das linhas). Então, basta ignorá-lo :)

1. No menu eclipse, vá para Janela-> Preferências-> Java-> Compilador
2. Desmarque a caixa de seleção "Adicionar atributos de número de linha ..."
3. Clique em Aplicar -> Sim
4. Marque a caixa de seleção "Adicionar atributo de número da linha ..."
5. Aplique novamente.
6. Ir feliz depuração

Isso corrigiu meu problema:

1. Janela -> preferências -> servidor -> ambientes de tempo de execução
2. Apache Tomcat -> editar
3. Selecione um JDK em vez de JRE

Para questões relacionadas ao Spring , considere que, em alguns casos, ele gera classes "sem números de linha"; por exemplo, uma @Serviceclasse anotada sem uma interface, adicione a interface e você poderá depurar. veja aqui um exemplo completo.

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

O serviço acima terá uma interface gerada pela mola, causando "números de linhas ausentes". A adição de uma interface real resolve o problema de geração:

public interface TestService {
    void doSomething();
}

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

Eu tenho a resposta para esse problema do lado do BlackBerry SDK: por algum motivo, não importa quantas vezes eu alterei as opções no compilador, o arquivo de configurações subjacente não foi alterado.

Na pasta .settings do seu projeto, procure um arquivo chamado org.eclipse.jdt.core.prefs .

Lá você pode modificar as configurações manualmente:

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

edit: Além disso, notei que às vezes eu posso ignorar o alerta que o Eclipse dá, e ele ainda pára no local necessário ... curioso e curioso ... Coloquei isso no balde de coisas que aprendemos a lidar com ao trabalhar como dev.

Isso funcionou para mim:

1. Abaixo Window --> Preferences --> Java --> Compiler --> Classfile Generation, todas as opções precisam ser True.
2. Feito debug="true"na <javac>tarefa build.xml .
3. Implantar aplicativo no tomcat pela guerra gerada pelo ant
4. Reiniciou o Tomcat no Debugmodo

Não sei se isso ainda é relevante, talvez outro marinheiro ache isso útil.

A mensagem aparece quando um arquivo de classe é compilado e os sinalizadores de depuração estão desativados.

No eclipse, você pode ativá-lo pelas opções mencionadas acima,

Janela -> Preferências -> Java -> Compilador -> Geração de arquivo de classe: "adicione atributos de número de linha ao arquivo de classe gerado"

Mas se você tiver um arquivo jar, obterá a saída compilada. Não há uma maneira fácil de corrigir esse problema.

Se você tiver acesso à fonte e usar ant para obter o arquivo jar, poderá modificar a tarefa ant da seguinte maneira.

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

Feliz depuração ..

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

Eu tentei quase todas as soluções aqui e sem sorte. Você tentou clicar em "Não me diga novamente"? Depois disso, reiniciei meu programa e tudo estava bem. O Eclipse atingiu meu ponto de interrupção como se nada estivesse errado.

A causa principal para mim foi que o Eclipse estava tentando configurar a depuração para objetos de proxy Spring CGLIB gerados automaticamente. A menos que você precise depurar algo nesse nível, ignore o problema.

Ajudaria se você indicasse a versão do eclipse que está usando e a tecnologia (Java JDT ou AJDT para Aspect Java ou C ++ CDT por exemplo), apenas para ter certeza.

No lado do Java, acho que o seu "Marquei a caixa de opções do compilador" refere-se a este

Em " Window --> Preferences --> Java --> Compiler --> Classfile Generation", todas as Class fileopções de geração ' ' são definidas como True:

• (1) adicionar atributos variáveis,
• (2) números addline,
• (3) adicione o nome do arquivo de origem,
• (4) preservar variáveis ​​locais não utilizadas.

O seu projeto tem as verificadas apenas no nível global (Preferências do Windows) ou no nível específico do projeto?

E você tem certeza de que a classe foi aberta (na qual você tenta definir um ponto de interrupção):

• é uma das suas fontes (e não vem de uma biblioteca de terceiros)
• é um .java, não um .class?

Tente limpar tudo e reconstruir tudo, verifique possíveis conflitos no jar .

Eu tive esse problema ao tentar iniciar o Tomcat no modo de depuração do Eclipse. Eu tinha um arquivo de compilação ANT cuidando da compilação e implantação. Depois de definir o sinalizador de depuração como true (como mencionado em outras respostas) e reimplementar o aplicativo, ele funcionou bem:

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

NOTA: se você acabou de adicionar o sinalizador de depuração e recompilar, ainda precisará reimplementar seu aplicativo no servidor, pois é aqui que o Eclipse está depurando os arquivos de classe. Muito óbvio, mas fácil de gastar uma hora ou mais, coçando a cabeça e se perguntando por que não está funcionando (acredite em mim).

tente alterar o que jrevocê usa. Defina jrena pasta em JDKvez disso.

Como tenho 6 versões diferentes do Java instaladas, tive que alterar minha conformidade JDK padrão para corresponder à versão Java que desejava usar. Por padrão, o Eclipse tinha o nível de conformidade do compilador definido como Java 1.7 quando tudo foi construído / compilado usando o Java 1.6.

Então tudo que eu fiz foi

1. No menu eclipse, vá para Janela-> Preferências-> Java-> Compilador
2. Em conformidade com o JDK, alterei o nível de conformidade do compilador de 1.7 para 1.6

Agora, o Eclipse não se queixa mais da "Não é possível inserir informações sobre o número de linhas ausentes do ponto de interrupção" e os pontos de interrupção de depuração realmente funcionam !!!

Se nada mais funcionar, abra a perspectiva de depuração, limpe todos os pontos de interrupção existentes e configure-os novamente.

Isso é explicado em detalhes aqui:

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

Apenas para referência futura, esta é a parte relevante da resposta (ignore o fato de se referir a um aplicativo Spring Boot, o comportamento é o mesmo para muitos outros casos):

Sempre que você define um ponto de interrupção no Eclipse / STS, o IDE tenta definir o ponto de interrupção na VM se você iniciar um aplicativo. É o que acontece no seu caso quando você executa o aplicativo de inicialização no modo de depuração.

Para cada classe que é carregada na JVM, o IDE verifica se precisa definir um ponto de interrupção ou não. Se ele decidir definir o ponto de interrupção, tentará fazê-lo (usando as informações da definição de ponto de interrupção no IDE, incluindo seu número de linha, já que você geralmente define pontos de interrupção de linha em um arquivo de origem em uma determinada linha).

Esta decisão (se deve definir o ponto de interrupção em uma determinada classe carregada ou não) verifica os tipos em que você definiu o ponto de interrupção, tipos anexos e classes internas. Isso garante que pontos de interrupção para classes internas (mesmo classes internas anônimas) sejam configurados para a JVM (e não sejam ignorados).

O Spring Boot gera uma classe interna para o seu controlador em tempo de execução (esta é a classe interna gerada pelo CGLIB que aparece na mensagem de erro). Quando a JVM carrega essa classe, ela tenta definir o ponto de interrupção do número da linha do tipo anexo (para essa classe interna). Como a classe interna gerada não possui nenhuma informação sobre o número da linha (não precisa ter informações sobre o número da linha), a definição do ponto de interrupção falha nessa classe interna com a mensagem de erro mencionada.

Quando o IDE carrega o tipo de anexo (sua própria classe de controlador), ele também tenta definir o ponto de interrupção da linha e obtém êxito. Isso é visualizado com o marcador de verificação no marcador de ponto de interrupção.

Portanto, você pode ignorar com segurança a mensagem de erro exibida. Para evitar que essa mensagem de erro seja exibida, você pode acessar as preferências (Java -> Debug) e desativar "Avisar quando não for possível instalar o ponto de interrupção devido à falta de atributos de número de linha".

Minha situação era semelhante:

• Eu estava depurando um teste JUnit
• Eu estava usando o Mockito para criar um espião, como em spyTask = spy(new Task())
• Coloquei o ponto de interrupção dentro da classe que estava espionando (dentro Task.java)

Esse ponto de interrupção gera o erro em questão, toda vez que corro Debug As... > JUnit Test

Para resolver o problema, mudei o ponto de interrupção para cima no teste real (dentro de TaskTest.java). Depois que a execução foi interrompida, adicionei o ponto de interrupção de volta onde estava, originalmente (dentro de Task.java).

Ainda recebi o mesmo erro, mas depois de clicar em "ok", o ponto de interrupção funcionou perfeitamente.

Espero que ajude alguém,

-gmale

Eu tive o mesmo problema ao fazer no servidor jetty e compilar novo arquivo .war pela ANT. Você deve criar a mesma versão do compilador jdk / jre e o caminho da construção (por exemplo, jdk 1.6v33, jdk 1.7, ....) depois de definir o Java Compiler como foi escrito anteriormente.

Fiz tudo e ainda não funcionei. A solução foi excluir os arquivos .class compilados e o destino do arquivo war gerado e agora está funcionando :)

Recebi esta mensagem com o Spring AOP (parece estar vindo da biblioteca CGLIB). Clicar em Ignorar parece funcionar bem, ainda posso depurar.

Encontrei mais um motivo para esta mensagem. Eu estava programando Scala. A solução foi:

1. Abra Executar -> Configurações de Depuração
2. Na guia Principal, na parte inferior, ao lado dos botões "Aplicar" e "Reverter", há um texto informando qual o Launcher que você está usando e, ao lado dele, existe um hiperlink dizendo "Selecionar outro". É um elemento de interface do usuário estranho, não parece acionável à primeira vista.
3. Use o link "Selecionar outro" e escolha "Iniciador do aplicativo Scala (novo depurador)". O outro parece não funcionar com Scala.

Agora a depuração deve funcionar. Observe que eu instalei o plug-in Scala IDE, esta opção pode não estar disponível se você não o tiver.

Acima as coisas não funcionaram para mim. As soluções abaixo finalmente funcionaram. Configurações de depuração -> Caminho da classe -> Entradas do usuário -> (Adicione a pasta src do projeto que você deseja depurar.)

Eu tive esse mesmo problema ao depurar um WAR (construído a partir de vários artefatos do projeto Eclipse) implementado no Tomcat.

Estou construindo tudo usando um script de compilação ANT. Se é isso que você está fazendo, verifique se o sinalizador debug = true está definido em todas as tarefas javac ant que você possui. Este foi o meu único problema - espero que ajude o seu problema!

Eu tive o mesmo erro com o JBoss 7.1. E fiz o mesmo que o Zefiro. Apenas ignorei o erro e consegui colocar pontos de interrupção normalmente. No meu caso, eu estava construindo o pensamento form construtor e esta é a minha tarefa 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>

Eu tive o mesmo problema, gastei muito tempo procurando soluções, mas essas soluções são inúteis. Portanto, estudo todos os casos e finalmente descobri que há um conflito entre as versões do JDK. Abaixo estão as etapas para resolver o problema: 1. Remova todas as versões do JDK e JRE, mantenha apenas uma versão. 2. Configure o sistema JAVA_HOME e o compilador java no Eclipse é o mesmo. Em alguns casos, o erro acima não desaparecerá, mas poderemos executar no modelo de depuração.

Depois que experimentei o mesmo erro quando usei junit e Mockito, esqueci de adicionar @PrepareForTest uma classe estática.

Adicionar código abaixo corrigiu meu problema.

@PrepareForTest({XXXXX.class})

_{Não tenho certeza se foi o mesmo caso.}

Meu problema era que eu tinha dois JARs e estava tentando substituir um pelo outro com base em sua ordem no Java Build Path => Order & Export guia no Eclipse, porque um era para depuração e o outro não (o JAR de depuração sendo o primeiro no pedido). Quando fiz dessa maneira, tive que anexar manualmente uma fonte.

Tentei remover o JAR sem depuração e colocá-lo no meu diretório \ WEB-INF \ lib \, limpeza, construção, etc., e funcionou. Desta vez (após remover a fonte anexada), ele automaticamente me deixaria navegar pelo código de depuração, sem precisar anexar nenhuma fonte manualmente. Pontos de interrupção e depuração também funcionaram.

Caso alguém ainda esteja tendo problemas, também tentei todas essas soluções específicas mencionadas nas outras respostas:

• Desmarque, aplique e verifique novamente Add line number attributes...
• Edição manual, org.eclipse.jdt.core.prefsconforme mencionado em outra resposta: https://stackoverflow.com/a/31588700/1599699
• Assegurando que o JAR estava sendo gerado com a depuração ativada.
• Alterando o nível de conformidade do JDK de 1,6 para 1,7 (correspondendo ao JDK que eu estava usando).

Também fiz o desligamento usual do servidor (e certifico-me de que o java.exe esteja realmente fechado ...), excluindo os diretórios \ build \ nos dois projetos, reiniciando o Eclipse com o parâmetro -clean, recriando o JAR de depuração, atualizando, limpeza e construção do projeto com o JAR de depuração, iniciando o servidor no modo de depuração, publicação / limpeza e ponto de interrupção.

Fiz tudo o que está listado acima ao compilar / construir os frascos - ainda tinha o mesmo problema.

Eventualmente, as alterações do jvmarg listadas abaixo ao iniciar o servidor é o que finalmente funcionou para mim:

1) Removido / Comentado um monte de jvm args pertencentes a javaagent e bootclasspath.

2) Ativou / não comentou a seguinte linha:

Então, quando inicio o servidor, sou capaz de atingir meus pontos de interrupção. Eu suspeito que o javaagent estava de alguma forma interferindo na capacidade do Eclipse de detectar números de linha.

Verifique / faça o seguinte:

1) Em "Janela -> Preferências -> Java -> Compilador -> Geração de arquivo de classe", todas as opções devem ser True:

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

2) Na pasta .settings do seu projeto, procure um arquivo chamado org.eclipse.jdt.core.prefs. Verifique ou configure org.eclipse.jdt.core.compiler.debug.lineNumber = generate

3) Se a janela de erro ainda aparecer, clique na caixa de seleção para não exibir a mensagem de erro.

4) Limpe e construa o projeto. Inicie a depuração.

Normalmente, a janela de erro não é mais exibida e as informações de depuração são exibidas corretamente.

Também encontrei esse problema. Estou usando um script de construção de formiga. Estou trabalhando em um aplicativo herdado, então estou usando o jdk versão 1.4.2. Isso costumava funcionar, então comecei a olhar em volta. Percebi que, na configuração Debug na guia JRE, a versão do Java havia sido definida como 1.7. Depois que eu mudei de volta para 1.4, funcionou.

Eu espero que isso ajude.

Eu estava tentando depurar o gerenciador de logs e precisava alterar o jre para um jdk e depois selecioná-lo na guia "principal", "Java Runtime Environment" | "tempo de execução JRE" da configuração de depuração, tudo estava bem.

Eu vi esse problema quando anotei uma classe com @ManagedBean (javax.annotation.ManagedBean). A mensagem de aviso surgiu ao executar o aplicativo recém-compatível no JBoss EAP 6.2.0. Ignorá-lo e executar de qualquer maneira não ajudou - o ponto de interrupção nunca foi atingido.

Eu estava chamando esse bean usando EL em uma página JSF. Agora ... é possível que o @ManagedBean não seja bom para isso (sou novo no CDI). Quando alterei minha anotação para @Model, meu bean foi executado, mas o aviso de ponto de interrupção também desapareceu e eu atingi o ponto de interrupção conforme o esperado.

Em resumo, certamente parecia que a anotação @ManagedBean atrapalhava os números das linhas, independentemente de ser a anotação errada a ser usada.

Verifique se o projeto em que a classe principal do tempo de execução está é o mesmo em que classe você possui pontos de interrupção . Caso contrário, verifique se os dois projetos estão no caminho de classe da configuração de execução e apareçam antes de quaisquer jars e pastas de classe.