NullPointerException 堆栈跟踪在没有调试代理的情况下不可用

本文介绍了NullPointerException 堆栈跟踪在没有调试代理的情况下不可用的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我最近发现了一个导致 NullPointerException 的错误.使用标准 slf4j 语句捕获并记录异常.代码如下:

I have recently found a bug that causes a NullPointerException. The exception is caught and logged using a standard slf4j statement. Abridged code below:

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

如您所见，没什么特别的.然而，在我们拥有的所有异常日志语句中，只有这个不打印堆栈跟踪.它打印的只是消息(表示为...")和异常类的名称(java.lang.NullPointerException).

As you can see, nothing fancy. However, of all the exception logging statements that we have, just this one does not print a stack trace. All it prints is the message (represented as "...") and the name of the exception class (java.lang.NullPointerException).

由于异常的堆栈跟踪是延迟加载的，我认为可能存在某种指令重新排序问题，并决定在日志语句之前调用 e.getStackTrace().这没什么区别.

Since the stack trace on an exception is lazy loaded, I thought maybe there is a instruction reordering issue of some sort and decided to call e.getStackTrace() before the log statement. This made no difference.

所以我决定在启用调试代理的情况下重新启动.然而，因为我什至附加到这个过程，我注意到现在堆栈跟踪正在打印.很明显，调试代理的存在导致一些额外的调试信息变得可用.

So I decided to restart with the debug agent enabled. However, because I even attached to the process, I noticed that now the stack traces were printing. So clearly the presence of the debug agent caused some additional debug information to become available.

从那时起我就修复了异常的根本原因.但我想了解为什么没有调试器就无法获得堆栈跟踪.有人知道吗?

I have since then fixed the root cause of the exception. But I would like to learn why the stack trace was unavailable without a debugger. Anyone know?

澄清:这不是日志问题.想象一下同样的try/catch子句，但是在catch中，我打印了以下值:

Clarification: this is not a logging issue. Imagine the same try/catch clause, but in the catch, I print the value of:

e.getStackTrace().length

如果没有调试器，它会打印0"，如果有调试器，它会打印一个正数(在本例中为 9).

Without a debugger this prints '0', with a debugger it prints a positive number (9 in this case).

更多信息:这发生在 JDK 1.6.0_13、64 位、amd64、linux 2.6.9 上

More info: this is happening on JDK 1.6.0_13, 64bit, amd64, linux 2.6.9

推荐答案

这段代码有没有可能是内循环?然后 JIT 编译器可能会将此调用堆栈编译为本机代码，从而丢失堆栈信息.然后，当您附加调试器时，它会禁用 JIT，使信息再次可用.

Is it possible that this code is in an inner loop? Then then JIT compiler might be compiling the call stack for this to native code, losing the stack information. Then when you attach the debugger it disables the JIT, making the information available again.

其他手动异常继续显示信息，因为 JIT 未优化.

The other manual exceptions keep displaying the information as the JIT is not optimising.

从此类源代码第 102 行的注释中，其他人有时会发生这种情况:

It looks like this can sometimes happen for others from a comment in this class source code at line 102:

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