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

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 checkbox de las opciones del comstackdor pero no tuve suerte.

Tenía 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 -> Comstackdor -> Generación de archivos de clase: se agregó la opción “Agregar atributos de número de línea al archivo de clase generado” . Hice una limpieza, recomstackción. Lo desactivé, recompile, verifique, recompile. Me aseguré de que el proyecto utilizara la configuración global. Todavía el mismo mensaje.

Cambié a la construcción de ant, usando

  

Aún así, el mismo mensaje.

No descubrí qué causó este mensaje y por qué no desapareció. Aunque parecía tener algo que ver con la ejecución de la sesión de depuración de Tomcat: cuando se desconecta, la recomstackció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 : efectivamente pude depurar y establecer puntos de interrupción, tanto antes como durante la depuración ( javap -l también mostró los números de línea). Así que solo ignóralo 🙂

  1. En el menú eclipse, vaya a Ventana-> Preferencias-> Java-> Comstackdor
  2. Desmarque la checkbox “Agregar atributos de número de línea …”
  3. Haga clic en Aplicar -> Sí
  4. Marque la checkbox “Agregar atributo de número de línea …”
  5. Aplicar de nuevo.
  6. Ir a la depuración feliz

sendero

Esto solucionó mi problema:

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

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 interfaz, agregue la interfaz y puede depurar. mira aquí 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 la spring que causa “números de línea faltantes”. Agregar una interfaz real resolver 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"); } } 

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

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

Allí puede modificar la configuración manualmente:

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

editar: Además de esto, me he dado cuenta de que a veces puedo ignorar la alerta que da Eclipse, y todavía se detiene en el lugar requerido … curioso y curioso … Puse esto en el cubo de cosas con las que aprendemos a lidiar cuando trabajas como dev.

Esto funcionó para mí:

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

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

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

En eclipse, puedes activarlo con las opciones mencionadas anteriormente,

Ventana -> Preferencias -> Java -> Comstackdor -> Generación de archivos de clase: “agregar atributos de número de línea al archivo de clase generado”

Pero si tiene un archivo jar, obtendrá la salida comstackda. 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.

   

Feliz depuración …

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

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

En el lado de Java, supongo que su “Marcó la checkbox de las opciones del comstackdor” se refiere a esto

En ” Window --> Preferences --> Java --> Compiler --> Classfile Generation Class file “, todas las opciones de generación del ” Class file ” se configuran en True:

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

¿Su proyecto los ha verificado solo a nivel global (Preferencias de viudas) o en el 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 tus fonts (y no proviene de una biblioteca de terceros)
  • es un .java , no una .class ?

Intenta limpiar todo y reconstruir todo, busca posibles conflictos de jar .

Tuve este problema al intentar iniciar Tomcat en modo de depuración desde Eclipse. Tenía un archivo de comstackción ANT que se ocupaba de la comstackción y la implementación. 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:

  

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

intente cambiar la jre que usa. En su lugar, configure la jre en la carpeta de JDK .

Como tengo 6 versiones diferentes de Java instaladas, tuve que cambiar mi conformidad con JDK por defecto para que coincidiera con la versión de Java que quería usar. Eclipse tenía por defecto el nivel de cumplimiento del comstackdor establecido en Java 1.7 cuando todo se comstackba / comstackba utilizando Java 1.6.

Entonces todo lo que hice fue

  1. En el menú eclipse, vaya a Ventana-> Preferencias-> Java-> Comstackdor
  2. De conformidad con JDK, cambié el nivel de cumplimiento del comstackdor de 1.7 a 1.6

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

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

Mi situación era similar:

  • Estaba depurando una prueba 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 abordar el problema, moví el punto de ruptura hacia arriba en la prueba real (dentro de TaskTest.java). Una vez que se detuvo la ejecución, 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,

-género

Tuve el mismo problema cuando estaba haciendo en el servidor de embarcadero y comstackndo el nuevo archivo .war de ANT. Debe hacer la misma versión del comstackdor jdk / jre y la ruta de comstackción (por ejemplo, jdk 1.6v33, jdk 1.7, ….) después de que tenga que establecer el comstackdor Java como se escribió anteriormente.

Hice todo y todavía no funcionaba. La solución fue eliminar los archivos comstackdos .class y el objective del archivo war generado y ahora funciona 🙂

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

Encontré una razón más para este mensaje. Estaba progtwigndo Scala. La solución fue:

  1. Open Run -> Configuraciones de depuración
  2. En la pestaña Principal, en la parte inferior, junto a los botones “Aplicar” y “Revertir”, hay un texto que indica qué Iniciador está utilizando y, junto a él, hay un hipervínculo que dice “Seleccionar otro”. Es un elemento de IU extraño, no parece procesable a primera vista.
  3. Use el enlace “Seleccionar otro” y elija “Iniciador Scala (nuevo depurador) Iniciador”. El otro parece no funcionar con Scala.

Ahora la depuración debería funcionar. Tenga en cuenta que he instalado el complemento Scala IDE, esta opción puede no estar disponible si no la tiene.

Intenté casi todas las soluciones aquí y no tuve suerte. ¿Has intentado hacer clic en “No volver a decirme”? Después de hacerlo, reinicié mi progtwig y todo estaba bien. Eclipse golpeó mi punto de quiebre como si nada estuviera mal.

La causa principal para mí era que Eclipse intentaba configurar la depuración de los objetos proxy Spring CGLIB autogenerados. A menos que necesite depurar algo en ese nivel, debe ignorar el problema.

Tuve el mismo problema al depurar un WAR (construido a partir de múltiples artefactos del proyecto Eclipse) desplegado 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 de depuración = verdadero esté configurado en cada tarea de javac que tengas. Este fue mi único problema. ¡Espero que ayude con tu problema!

Tuve el mismo error con JBoss 7.1 .. E hice lo mismo que con Zefiro. Simplemente ignoré el error y pude ubicar puntos de interrupción normalmente. En mi caso yo estaba construyendo el generador de pensamientos y esta es mi tarea javac:

         

Tengo el mismo problema, pasé mucho tiempo buscando una solución pero estas soluciones no son útiles, así que estudio todos los casos, finalmente descubrí que hay un conflicto entre versiones de JDK. A continuación se detallan los pasos para resolver el problema: 1. Elimine toda la versión de JDK y JRE, conserve solo una versión. 2. Configure el sistema JAVA_HOME y el comstackdor de Java en Eclipse es el mismo. En algunos casos, el error anterior no desaparecerá, pero podemos ejecutar en el modelo de depuración.

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

Agregar código a continuación solucionó mi problema.

 @PrepareForTest({XXXXX.class}) 

No estoy seguro de que fuera el mismo caso.

Esto se explica en detalle aquí:

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

Solo para referencia futura, 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 VM si inicia una aplicación. Eso es lo que sucede en su caso cuando ejecuta la aplicación de inicio 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 generalmente establece puntos de corte de línea en un archivo fuente en una línea determinada).

Esta decisión (si establecer o no el punto de interrupción en una clase cargada dada) verifica los tipos en los que establece el punto de interrupción, incluyendo tipos y clases internas. Esto asegura que los puntos de corte para las clases internas (incluso las clases internas anónimas) se establecen en la JVM (y no se ignoran).

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 adjunto (para esta clase interna). Dado que la clase interna generada no tiene información de número de línea (no es necesario que tenga 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 adjunto (su propia clase de controlador), también intenta establecer el punto de corte 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 con seguridad el mensaje de error que aparece. Para evitar que aparezca este mensaje de error, puede ir a las preferencias (Java -> Depurar) y deshabilitar “Advertir cuando no se puede instalar el punto de interrupción debido a los atributos de número de línea faltantes”.

Hice todo lo que se menciona arriba mientras comstackba / construía los flasks, todavía tenía el mismo problema.

Eventualmente, los cambios de jvmarg que figuran a continuación, mientras que el inicio del servidor es lo que finalmente funcionó para mí:

1) Se eliminó / Comentó un grupo de jvm args pertenecientes a javaagent y bootclasspath.

2) Activado / no comentado la siguiente línea:

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

Compruebe / haga lo siguiente:

1) En “Ventana -> Preferencias -> Java -> Comstackdor -> Generación de archivos de clase”, todas las opciones deben ser True.

 (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 establezca org.eclipse.jdt.core.compiler.debug.lineNumber = generate

3) Si aún aparece la ventana de error, haga clic en la checkbox 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.

Me encontré con este problema también. Estoy usando un script de construcción ant. Estoy trabajando en una aplicación heredada, así que estoy usando jdk versión 1.4.2. Esto solía funcionar así que comencé 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é a 1.4 funcionó.

Espero que esto ayude.

Estaba intentando depurar el gestor de registro y necesitaba cambiar el jre a un jdk y luego seleccionar este jdk en la pestaña “principal”, “Java Runtime Environment” | “runtime JRE” de la configuración de depuración, todo estaba bien.

Vi este problema cuando anoté una clase con @ManagedBean (javax.annotation.ManagedBean). El mensaje de advertencia apareció cuando se ejecutaba la aplicación recién comstackda en JBoss EAP 6.2.0. Ignorarlo y correr de todos modos no ayudó, el punto de quiebre nunca se alcanzó.

Llamaba a ese frijol usando EL en una página JSF. Ahora … es posible que @ManagedBean no sea bueno para eso (soy nuevo en CDI). Cuando cambié mi anotación a @Model, mi bean se ejecutó pero la advertencia del punto de interrupción también desapareció y llegué al punto de interrupción como se esperaba.

En resumen, parecía como si la anotación @ManagedBean hubiera estropeado los números de las líneas, independientemente de si era la anotación incorrecta o no.

Asegúrese de que el proyecto en el que está la clase principal del tiempo de ejecución sea el mismo proyecto en el que está la clase en la que tiene puntos de interrupción . De lo contrario, asegúrese de que ambos proyectos se encuentren en la ruta de clase de la configuración de ejecución y aparezcan antes de cualquier jarra y carpeta de clase.

Tuve el mismo problema con un proyecto específico e intenté restablecer los atributos del número de línea en Ventana-> Preferencias … Luego me di cuenta de que cada proyecto tiene su propia configuración para los atributos del número de línea. Haga clic con el botón derecho en el proyecto, vaya a propiedades, seleccione JavaCompiler y marque la casilla “Agregar atributos de número de línea …”

Si la solución anterior no funciona y comenzaste a tener ese problema después de haber inyectado la spring, el problema puede ser que no usaste la interfaz para la clase inyectada. Intenta hacer la inyección con la clase que implementa una interfaz que resolvería el problema. Para un ejemplo, siga el enlace: No se puede instalar el problema de punto de interrupción para la creación de bean