Java NullPointerException 堆栈跟踪在没有调试代理的情况下不可用
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1076191/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
NullPointerException stack trace not available without debug agent
提问by omerkudat
I have recently found a bug that causes a NullPointerException. The exception is caught and logged using a standard slf4j statement. Abridged code below:
我最近发现了一个导致 NullPointerException 的错误。使用标准 slf4j 语句捕获并记录异常。精简代码如下：
for(Action action : actions.getActions()) {
try {
context = action.execute(context);
} catch (Exception e) {
logger.error("...", e);
break;
}
}
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).
如您所见，没什么特别的。然而，在我们拥有的所有异常日志语句中，只有这个不打印堆栈跟踪。它打印的只是消息（表示为“...”）和异常类的名称 (java.lang.NullPointerException)。
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.
由于异常的堆栈跟踪是延迟加载的，我认为可能存在某种指令重新排序问题，并决定在日志语句之前调用 e.getStackTrace()。这没有任何区别。
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?
从那以后，我修复了异常的根本原因。但我想了解为什么没有调试器就无法获得堆栈跟踪。有人知道吗？
Clarification: this is not a logging issue. Imagine the same try/catch clause, but in the catch, I print the value of:
澄清：这不是日志记录问题。想象一下相同的 try/catch 子句，但在 catch 中，我打印了以下值：
e.getStackTrace().length
Without a debugger this prints '0', with a debugger it prints a positive number (9 in this case).
如果没有调试器，它会打印“0”，如果有调试器，它会打印一个正数（在这种情况下为 9）。
More info: this is happening on JDK 1.6.0_13, 64bit, amd64, linux 2.6.9
更多信息：这发生在 JDK 1.6.0_13, 64bit, amd64, linux 2.6.9
采纳答案by Nick Fortescue
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 编译器可能会将此调用堆栈编译为本机代码，从而丢失堆栈信息。然后，当您附加调试器时，它会禁用 JIT，使信息再次可用。
The other manual exceptions keep displaying the information as the JIT is not optimising.
由于 JIT 未优化，其他手动异常继续显示信息。
It looks like this can sometimes happen for others from a comment in this class source code at line 102:
从此类源代码第 102 行的注释中，其他人有时会发生这种情况：
http://logging.apache.org/log4j/1.2/xref/org/apache/log4j/spi/LocationInfo.html
http://logging.apache.org/log4j/1.2/xref/org/apache/log4j/spi/LocationInfo.html
回答by seth
I can replicate this but it seems kind of weird that this would be happening in your Action somewhere.
我可以复制这个，但在你的 Action 某处发生这种情况似乎有点奇怪。
If you call setStackTrace with an empty array, that'll cause only the text to be shown.
如果您使用空数组调用 setStackTrace，则只会显示文本。
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;
}
}
Running it....
运行它....
% java Fark
java.lang.NullPointerException
at Fark.throwMe(Fark.java:15)
at Fark.main(Fark.java:5)
% java Fark nothing
java.lang.NullPointerException
回答by vesparun
With the JVM flag -XX:-OmitStackTraceInFastThrow you can disable the performance optimization of the JVM for this use case. IF this parameter is given, which disables the flag, the stacktrace will be available.
使用 JVM 标志 -XX:-OmitStackTraceInFastThrow，您可以为此用例禁用 JVM 的性能优化。如果给出这个参数，禁用标志，堆栈跟踪将可用。
For more information please have a look at the following release notes:
有关更多信息，请查看以下发行说明：
"The compiler in the server VM now provides correct stack backtraces for all "cold" built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag: -XX:-OmitStackTraceInFastThrow." http://java.sun.com/j2se/1.5.0/relnotes.html
“服务器VM中的编译器现在为所有“冷”内置异常提供正确的堆栈回溯。出于性能考虑，当此类异常抛出几次时，该方法可能会重新编译。重新编译后，编译器可能会选择一个使用不提供堆栈跟踪的预分配异常的更快策略。要完全禁用预分配异常的使用，请使用此新标志：-XX:-OmitStackTraceInFastThrow。” http://java.sun.com/j2se/1.5.0/relnotes.html
