java - El seguimiento de la pila NullPointerException no está disponible sin el agente de depuración

logging stack-trace

Question

Recientemente he encontrado un error que causa una NullPointerException. La excepción se captura y se registra usando una declaración slf4j estándar. Código abreviado a continuación:

for(Action action : actions.getActions()) {
try {
context = action.execute(context);
} catch (Exception e) {
logger.error("...", e);
break;
}
}

Como puede ver, nada lujoso. Sin embargo, de todas las declaraciones de registro de excepciones que tenemos, solo esta no imprime un seguimiento de pila. Todo lo que imprime es el mensaje (representado como "...") y el nombre de la clase de excepción (java.lang.NullPointerException).

Dado que el seguimiento de la pila en una excepción está cargado de forma diferida, pensé que tal vez haya un problema de orden de reordenación de alguna clase y decidí llamar a e.getStackTrace () antes de la declaración de registro. Esto no hizo diferencia.

Así que decidí reiniciar con el agente de depuración habilitado. Sin embargo, debido a que incluso adjunté el proceso, noté que ahora los trazos de pila estaban imprimiendo. Entonces, claramente, la presencia del agente de depuración provocó que estuviera disponible cierta información de depuración adicional.

Desde entonces, he corregido la causa raíz de la excepción. Pero me gustaría saber por qué el seguimiento de la pila no estaba disponible sin un depurador. ¿Nadie sabe?

Aclaración: este no es un problema de registro . Imagine la misma cláusula try / catch, pero en la captura, imprimo el valor de:

e.getStackTrace().length

Sin un depurador esto imprime ''0'', con un depurador imprime un número positivo (9 en este caso).

Más información: esto está sucediendo en JDK 1.6.0_13, 64 bits, amd64, linux 2.6.9

Answer 1

¿Es posible que este código esté en un bucle interno? Entonces, el compilador JIT podría estar compilando la pila de llamadas para este código nativo, perdiendo la información de la pila. Luego, cuando conecta el depurador, deshabilita el JIT, haciendo que la información vuelva a estar disponible.

Las otras excepciones manuales siguen mostrando la información ya que el JIT no se está optimizando.

Parece que esto puede suceder a veces para otros a partir de un comentario en este código fuente de clase en la línea 102:

http://logging.apache.org/log4j/1.2/xref/org/apache/log4j/spi/LocationInfo.html

Answer 2

Con el indicador JVM -XX: -OmitStackTraceInFastThrow, puede desactivar la optimización del rendimiento de la JVM para este caso de uso. Si se proporciona este parámetro, que desactiva el indicador, la pila de seguimiento estará disponible.

Para obtener más información, consulte las siguientes notas de la versión:

"El compilador en la máquina virtual del servidor ahora proporciona trazas inversas correctas para todas las excepciones integradas" frías ". Por motivos de rendimiento, cuando se lanza una excepción de este tipo varias veces, el método puede ser recompilado. Después de la recompilación, el compilador puede elegir una táctica más rápida utilizando excepciones preasignadas que no proporcionan un seguimiento de pila. Para deshabilitar por completo el uso de excepciones preasignadas, use este nuevo indicador: -XX: -OmitStackTraceInFastThrow ". http://java.sun.com/j2se/1.5.0/relnotes.html

Answer 3

Puedo replicar esto, pero parece un poco extraño que esto suceda en tu Acción en alguna parte.

Si llama a setStackTrace con una matriz vacía, eso solo hará que se muestre el texto.

 public class Fark {
public static void main(String[] args) {
try {
Fark.throwMe(args.length != 0);
}
catch (Exception e) {
e.printStackTrace();
}
}
public static final void throwMe(boolean arg) throws Exception{
Exception e = new NullPointerException();
if (arg) {
e.setStackTrace(new StackTraceElement[0]);
}
throw e;
}
}

Correrlo ...

% java Fark
java.lang.NullPointerException
at Fark.throwMe(Fark.java:15)
at Fark.main(Fark.java:5)
% java Fark nothing
java.lang.NullPointerException