pasar - trabajar c en eclipse

Eclipse: no se puede instalar el punto de interrupción debido a que faltan atributos de número de línea

Question

Recibo este extraño error en Eclipse al intentar establecer un punto de interrupción.

Unable to insert breakpoint Absent Line Number Information

Marqué la casilla de verificación de las opciones del compilador, pero no tuve suerte.

Answer 1

1. En el menú de eclipse, vaya a Ventana-> Preferencias-> Java-> Compilador
2. Desmarcar casilla de verificación "Agregar atributos de número de línea ..."
3. Haga clic en Aplicar -> Sí
4. Marque la casilla "Agregar atributo de número de línea ..."
5. Aplicar de nuevo.
6. Vaya feliz depurando

Answer 2

Asegúrese de que el proyecto en el que se encuentra la clase principal del tiempo de ejecución sea el mismo proyecto en el que se encuentra la clase en la que tiene puntos de interrupción . De lo contrario, asegúrese de que ambos proyectos estén en la ruta de clase de la configuración de ejecución y que aparezcan antes de los archivos jar y las carpetas de clase.

Answer 3

Como tengo 6 versiones diferentes de Java instaladas, tuve que cambiar mi cumplimiento de JDK predeterminado para que coincidiera con la versión de Java que quería usar. Eclipse de manera predeterminada tenía el nivel de cumplimiento del compilador establecido en Java 1.7 cuando todo se compiló / compiló usando Java 1.6.

Así que todo lo que hice fue

1. En el menú de eclipse, vaya a Ventana-> Preferencias-> Java-> Compilador
2. Bajo JDK Compliance, cambié el nivel de cumplimiento del compilador de 1.7 a 1.6

Ahora Eclipse ya no se queja de que "No se puede insertar la información del número de línea ausente del punto de interrupción" y los puntos de interrupción de depuración realmente funcionan.

Answer 4

Compruebe / haga lo siguiente:

1) En "Ventana -> Preferencias -> Java -> Compilador -> Generación de archivo de clase", todas las opciones deben ser verdaderas:

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

2) En la carpeta .settings de su proyecto, busque un archivo llamado org.eclipse.jdt.core.prefs. Verifique o configure org.eclipse.jdt.core.compiler.debug.lineNumber = generar

3) Si aún aparece la ventana de error, haga clic en la casilla de verificación para no mostrar el mensaje de error.

4) Limpiar y construir el proyecto. Comience a depurar.

Normalmente, la ventana de error ya no se muestra y la información de depuración se muestra correctamente.

Answer 5

Encontré otra razón para este mensaje. Estaba programando Scala. La solución fue:

1. Abrir Ejecutar -> Depurar configuraciones
2. En la pestaña Principal, en la parte inferior, junto a los botones "Aplicar" y "Revertir", hay un texto que indica qué Lanzador está utilizando y, junto a él, hay un hipervínculo que dice "Seleccionar otro". Es un elemento extraño de la interfaz de usuario, no parece accionable a primera vista.
3. Use el enlace "Seleccionar otro" y elija "Lanzador de la aplicación Scala (nuevo depurador)". El otro no parece funcionar con Scala.

Ahora la depuración debería funcionar. Tenga en cuenta que he instalado el complemento IDE de Scala, es posible que esta opción no esté disponible si no la tiene.

Answer 6

Estaba intentando depurar el administrador de registro y necesitaba cambiar el jre a un jdk y luego seleccionar este jdk en la pestaña "principal", "Java Runtime Environment" | "JRE de tiempo de ejecución" de la configuración de depuración, entonces todo estaba bien.

Answer 7

Esto funcionó para mí:

1. En Window --> Preferences --> Java --> Compiler --> Classfile Generation , todas las opciones deben ser True .
2. Made debug="true" en la tarea build.xml <javac> .
3. Implementar aplicación en el tomcat por la guerra generada por ant.
4. Reinició el Tomcat en modo de Debug

Answer 8

Esto se explica en detalle aquí:

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

Solo para futuras referencias, esta es la parte relevante de la respuesta (ignore el hecho de que se refiere a una aplicación Spring Boot, el comportamiento es el mismo para muchos otros casos):

Cada vez que establece un punto de interrupción en Eclipse / STS, el IDE intenta establecer el punto de interrupción en la máquina virtual si inicia una aplicación. Eso es lo que sucede en su caso cuando ejecuta la aplicación de arranque en modo de depuración.

Para cada clase que se carga en la JVM, el IDE verifica si necesita establecer un punto de interrupción o no. Si decide establecer el punto de interrupción, intenta hacerlo (utilizando la información de la definición de punto de interrupción en el IDE, incluido su número de línea, ya que normalmente establece los puntos de interrupción de línea en un archivo de origen en una línea determinada).

Esta decisión (ya sea para establecer el punto de interrupción en una clase cargada dada o no) verifica los tipos en los que establece el punto de interrupción, los tipos adjuntos y las clases internas. Esto asegura que los puntos de interrupción para las clases internas (incluso las clases internas anónimas) se establezcan en la JVM (y no se ignoren).

Spring Boot genera una clase interna para su controlador en tiempo de ejecución (esta es la clase interna generada por CGLIB que aparece en el mensaje de error). Cuando la JVM carga esa clase, intenta establecer el punto de corte del número de línea del tipo envolvente (para esta clase interna). Dado que la clase interna generada no tiene ninguna información de número de línea (no necesita tener información de número de línea), la configuración del punto de interrupción falla para esta clase interna con el mensaje de error mencionado.

Cuando el IDE carga el tipo de envolvente (su propia clase de controlador), también intenta establecer el punto de interrupción de la línea y lo logra. Esto se visualiza con el marcador de verificación en el marcador de punto de interrupción.

Por lo tanto, puede ignorar de forma segura el mensaje de error que aparece. Para evitar que aparezca este mensaje de error, puede ir a las preferencias (Java -> Depurar) y deshabilitar "Avisar cuando no pueda instalar un punto de interrupción debido a que faltan atributos de número de línea".

Answer 9

Esto solucionó mi problema:

1. Ventana -> preferencias -> servidor -> entornos de ejecución
2. Apache Tomcat -> editar
3. Seleccione un JDK en lugar de JRE

Answer 10

Hice todo lo que se menciona arriba mientras compilaba / construía los frascos, aún tenía el mismo problema.

Finalmente, los cambios en jvmarg que se enumeran a continuación al iniciar el servidor es lo que finalmente me funcionó:

1) Eliminado / comentado un montón de argumentos jvm pertenecientes a javaagent y bootclasspath.

2) Encendido / sin comentar la siguiente línea:

Luego, cuando inicio el servidor, puedo alcanzar mis puntos de interrupción. Sospecho que el javaagent estaba interfiriendo de alguna manera con la capacidad de Eclipse para detectar números de línea.

Answer 11

Me encontré con este problema también. Estoy usando un script de compilación de ant. Estoy trabajando en una aplicación heredada, así que estoy usando la versión 1.4.2 de jdk. Esto solía funcionar, así que empecé a mirar alrededor. Noté que bajo la configuración de depuración en la pestaña JRE, la versión de Java se había establecido en 1.7. Una vez que lo cambié de nuevo a 1.4 funcionó.

Espero que esto ayude.

Answer 12

Mi situación era similar:

• Estaba depurando una prueba de JUnit
• Estaba usando Mockito para crear un espía, como en spyTask = spy(new Task())
• Puse el punto de interrupción dentro de la clase que estaba espiando (dentro de Task.java )

Este punto de interrupción genera el error en cuestión, cada vez que ejecuto Debug As... > JUnit Test

Para solucionar el problema, moví el punto de ruptura ''arriba'' a la prueba real (dentro de TaskTest.java). Una vez que la ejecución se detuvo, agregué el punto de interrupción donde lo tenía, originalmente (dentro de Task.java).

Todavía tengo el mismo error, pero después de hacer clic en "ok", el punto de interrupción funcionó bien.

Espero que ayude a alguien,

-gale

Answer 13

No sé si esto sigue siendo relevante, tal vez otro navegante lo encuentre útil.

El mensaje aparece cuando uno tiene un archivo de clase compilado y los indicadores de depuración están desactivados.

En eclipse, puede activarlo mediante las opciones antes mencionadas,

Ventana -> Preferencias -> Java -> Compilador -> Generación de archivo de clase: "agregar atributos de número de línea al archivo de clase generado"

Pero si tienes un archivo jar, obtendrías la salida compilada. No hay una manera fácil de solucionar este problema.

Si tiene acceso a la fuente y usa ant para obtener el archivo jar, puede modificar la tarea ant de la siguiente manera.

  <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 depuración ..

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

Answer 14

Para cuestiones relacionadas con Spring , considere que en algunos casos genera clases "sin números de línea"; por ejemplo, una clase anotada @Service sin una interfaz, agregue la interfaz y puede depurar. Vea here para un ejemplo completo.

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

El servicio anterior tendrá una interfaz generada por Spring causando "números de línea faltantes". Añadiendo una interfaz real resuelve el problema de generación:

public interface TestService {
    void doSomething();
}

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

Answer 15

Probé casi todas las soluciones aquí y no tuve suerte. ¿Intentaste hacer clic en "No me digas otra vez"? Después de hacerlo reinicié mi programa y todo estuvo bien. Eclipse golpeó mi punto de ruptura como si nada estuviera mal.

La causa principal para mí fue que Eclipse estaba tratando de configurar la depuración de los objetos proxy Spring CGLIB generados automáticamente. A menos que necesite depurar algo en ese nivel, debe ignorar el problema.

Answer 16

Recibí este mensaje con Spring AOP (parece provenir de la biblioteca CGLIB). Al hacer clic en Ignorar parece funcionar bien, todavía puedo depurar.

Answer 17

Sería útil si indicara la versión de eclipse que está utilizando y la tecnología (Java JDT, o AJDT para Aspect Java, o C ++ CDT, por ejemplo), para estar seguro.

En el lado de Java, supongo que su "Marque la casilla de verificación de las opciones del compilador" se refiere a this

En " Window --> Preferences --> Java --> Compiler --> Classfile Generation Class file ", todas las opciones de generación de '' Class file '' se configuran en Verdadero:

• (1) agregar atributos variables,
• (2) números adicionales,
• (3) agregar el nombre del archivo fuente,
• (4) preservar las variables locales no utilizadas.

¿Tiene su proyecto comprobados solo a nivel global (Preferencias de viudas) o a nivel específico del proyecto?

¿Y está seguro de que la clase se abrió (en la que intenta establecer un punto de interrupción)?

• es una de sus fuentes (y no proviene de una biblioteca de terceros)
• es un .java , no un .class ?

Trate de limpiar todo y reconstruir todo, verifique si hay posibles conflictos de jarra .

Answer 18

Si la solución anterior no funciona y comenzó a tener ese problema después de realizar una inyección de Spring Bean, el problema puede ser que no usó la interfaz para la clase inyectada. Trate de hacer la inyección con la clase que implementa una interfaz resolvería el problema. Para ver un ejemplo, siga el enlace: No se puede instalar el problema de punto de interrupción para la creación del bean

Answer 19

Si nada más funciona, abra la perspectiva de depuración, borre todos los puntos de interrupción existentes y luego vuelva a establecerlos.

Answer 20

Tengo el mismo problema, dediqué mucho tiempo a buscar una solución, pero estas soluciones son inútiles. Por lo tanto, estudio todos los casos. Finalmente, descubrí que hay un problema entre las versiones de JDK. A continuación se muestran los pasos para resolver el problema: 1. Elimine todas las versiones de JDK y JRE, mantenga solo una versión. 2. Establecer el sistema JAVA_HOME y el compilador java en Eclipse es el mismo. En algunos casos, el error anterior no desaparecerá, pero podremos ejecutar en el modelo de depuración.

Answer 21

Tengo la respuesta a este problema desde el punto de vista de BlackBerry SDK: por alguna razón, no importa cuántas veces haya cambiado las opciones en el compilador, el archivo de configuración subyacente real no cambió.

Eche un vistazo en la carpeta .settings de su proyecto para ver un archivo llamado org.eclipse.jdt.core.prefs .

Allí puede modificar la configuración manualmente:

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

edit: más allá de esto, he notado que a veces puedo ignorar la alerta que Eclipse da, y aún se detendrá en el lugar requerido ... curiosidad y curiosidad ... Pongo esto en el cubo de cosas con las que aprendemos a lidiar cuando se trabaja como dev.

Answer 22

Tuve el mismo error con JBoss 7.1 .. E hice lo mismo que Zefiro. Simplemente ignoré el error y pude colocar puntos de interrupción normalmente. En mi caso, estaba construyendo un creador de hormigas de pensamiento y esta es mi tarea 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>

Answer 23

Tuve el mismo mensaje de error en Eclipse 3.4.1, SUN JVM1.6.0_07 conectado a Tomcat 6.0 (ejecutándose en modo de depuración en una máquina diferente, Sun JVM1.6.0_16, la conexión de depuración funcionó correctamente).

Ventana -> Preferencias -> Java -> Compilador -> Generación de archivo de clase: se marcó "agregar atributos de número de línea al archivo de clase generado" . Hice un limpio, recompilar. Lo hice deseleccionar, recompilar, comprobar, recompilar. Me aseguré de que el proyecto usara la configuración global. Sigue con el mismo mensaje.

Cambié a construir hormigas, usando

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

Aún así, mismo mensaje.

No descubrí qué causó este mensaje y por qué no desapareció. Aunque parecía tener algo que ver con la sesión de depuración de Tomcat en ejecución: cuando está desconectado, la recompilación resuelve el problema. Pero al conectar el depurador a Tomcat o al establecer nuevos puntos de interrupción durante una sesión de depuración conectada, apareció nuevamente.

Sin embargo, resultó que el mensaje era incorrecto : de hecho, pude depurar y establecer puntos de interrupción, tanto antes como durante la depuración ( javap -l también mostró números de línea). Así que ignóralo :)

Answer 24

Tuve el mismo problema con un proyecto específico y traté de restablecer los atributos de número de línea en Ventana-> Preferencias ... Luego me di cuenta de que cada proyecto tiene su propia configuración para los atributos de número de línea. Haga clic con el botón derecho en el proyecto, ingrese a las propiedades, elija JavaCompiler y marque la casilla "Agregar atributos de número de línea ..."

Answer 25

Tuve el mismo problema cuando estaba en el servidor Jetty y compilando un nuevo archivo .war por ANT. Debe crear la misma versión del compilador jdk / jre y la ruta de compilación (por ejemplo, jdk 1.6v33, jdk 1.7, ...) después de que tenga que configurar el compilador Java como se escribió antes.

Lo hice todo y todavía no funciona. La solución fue eliminar los archivos .class compilados y el destino del archivo war generado y ahora está funcionando :)

Answer 26

Tuve este mismo problema al depurar un WAR (construido a partir de múltiples artefactos del proyecto Eclipse) implementado en Tomcat.

Estoy construyendo todo usando un script de construcción ANT. Si esto es lo que estás haciendo, asegúrate de que el indicador debug = true esté establecido en cada tarea ant javac que tengas. Este fue mi único problema - ¡Espero que ayude a su problema!

Answer 27

Tuve este problema al intentar iniciar Tomcat en modo de depuración desde Eclipse. Tuve un archivo de compilación ANT que se encarga de compilar y desplegar. Después de establecer el indicador de depuración en verdadero (como se menciona en otras respuestas) y volver a implementar la aplicación funcionó bien:

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

NOTA: si acaba de agregar la marca de depuración y ha vuelto a compilar, todavía necesita volver a implementar su aplicación en el servidor, ya que aquí es donde Eclipse está depurando los archivos de clase. Muy obvio, pero es fácil pasar una hora más o menos rascándote la cabeza y preguntándote por qué no funciona (confía en mí).

Answer 28

Una vez que experimenté el mismo error cuando usé Junit y Mockito, olvidé agregar @PrepareForTest para una clase estática.

Añadir el siguiente código solucionado mi problema.

@PrepareForTest({XXXXX.class})

_{No estoy seguro de que fuera el mismo caso.}

Answer 29

Vi este problema cuando anoté una clase con @ManagedBean (javax.annotation.ManagedBean). Apareció un mensaje de advertencia al ejecutar la aplicación recientemente cumplida en JBoss EAP 6.2.0. Ignorarlo y correr de todos modos no ayudó, nunca se llegó al punto de interrupción.

Estaba llamando a ese bean usando EL en una página JSF. Ahora ... es posible que @ManagedBean no sirva para eso (soy nuevo en CDI). Cuando cambié mi anotación a @Model, mi bean se ejecutó, pero la advertencia de punto de interrupción también desapareció y alcancé el punto de interrupción como se esperaba.

En resumen, ciertamente parecía que la anotación @ManagedBean arruinaba los números de las líneas, independientemente de si era o no la anotación incorrecta de usar.

Answer 30

intente cambiar el jre que usa. Ponga el jre en la carpeta de JDK lugar.