NullPointerException in Java with no StackTrace

Question

I've had instances of our Java code catch a NullPointerException, but when I try to log the StackTrace (which basically ends up calling Throwable.printStackTrace() ), all I get is:

java.lang.NullPointerException

Has anyone else come across this? I tried googling for "java null pointer empty stack trace" but didn't come across anything like this.

What is the context? Are there multiple threads involved? I've had issues trying to get the stack trace of an exception in a SwingWorker. — Michael Myers, Mar 09 '10 at 18:26
@Bozho - nope - not sure how to reproduce the NullPointer yet. — Edward Shtern, Mar 10 '10 at 16:58
related: http://stackoverflow.com/questions/1076191/nullpointerexception-stack-trace-not-available-without-debug-agent — Joshua Goldberg, Jan 30 '12 at 19:04
More info on `-XX:-OmitStackTraceInFastThrow` in the dup: https://stackoverflow.com/questions/4659151/recurring-exception-without-a-stack-trace-how-to-reset — Vadzim, Dec 07 '17 at 18:47

score 561 · Accepted Answer · edited Oct 26 '22 at 19:58

561

You are probably using the HotSpot JVM (originally by Sun Microsystems, later bought by Oracle, part of the OpenJDK), which performs a lot of optimization. To get the stack traces back, you need to pass the following option to the JVM:

-XX:-OmitStackTraceInFastThrow

The optimization is that when an exception (typically a NullPointerException) occurs for the first time, the full stack trace is printed and the JVM remembers the stack trace (or maybe just the location of the code). When that exception occurs often enough, the stack trace is not printed anymore, both to achieve better performance and not to flood the log with identical stack traces.

To see how this is implemented in the HotSpot JVM, grab a copy of it and search for the global variable OmitStackTraceInFastThrow. Last time I looked at the code (in 2019), it was in the file graphKit.cpp.

edited Oct 26 '22 at 19:58

Marcin Orlowski

72,056
11
123
141

answered Jun 09 '10 at 21:32

Roland Illig

40,703
10
88
121

1

Thanks for the tip. Any idea if there are any hidden gotchas to passing this option (it seems pretty innocuous as long as my application doesn't throw a ton of exceptions)? – Edward Shtern Jun 11 '10 at 17:48
There are no hidden gotchas that I know of. When you look at the Hotspot source code, you can see that this option is only used in one place (graphKit.cpp). And that looks fine to me. – Roland Illig Jun 13 '10 at 11:14
37

Thought I'd add the additional bit of information that when the stack trace gets optimized away, it's because it has gotten fully handled at least once: http://jawspeak.com/2010/05/26/hotspot-caused-exceptions-to-lose-their-stack-traces-in-production-and-the-fix/ – sharakan Jun 19 '12 at 14:56
1

I am running an OpenJDK JVM, version 1.8.0u171 (Debian 9), and it seems to accept the `-XX:-OmitStackTraceInFastThrow` flag as well. I've yet to confirm if that was why I was also failing to print stack-traces (e.g., using `e.printStackTrace`), but it seems highly likely. I've expanded the answer to reflect this discovery. – Chris W. Jun 05 '18 at 17:12
In our case first 125 exceptions had a stack trace, and then the rest across 3 rotations of log files had none. This answer was very helpful in finding the culprit. – sukhmel May 27 '20 at 10:03

score 69 · Answer 2 · answered Mar 09 '10 at 18:50

69

As you mentioned in a comment, you're using log4j. I discovered (inadvertently) a place where I had written

LOG.error(exc);

instead of the typical

LOG.error("Some informative message", e);

through laziness or perhaps just not thinking about it. The unfortunate part of this is that it doesn't behave as you expect. The logger API actually takes Object as the first argument, not a string - and then it calls toString() on the argument. So instead of getting the nice pretty stack trace, it just prints out the toString - which in the case of NPE is pretty useless.

Perhaps this is what you're experiencing?

answered Mar 09 '10 at 18:50

Steven Schlansker

37,580
14
81
100

+1: This would explain the described behavior, and you are not the only one who discovered this :) – Peter Lang Mar 09 '10 at 18:59
4

We actually have a standard policy of never using the first form above (LOG.error(exc);) - we always use the 2 parameter signature so that we add some descriptive statement to the logs instead of just a raw stacktrace. – Edward Shtern Mar 09 '10 at 19:25
6

Sure, but policy doesn't mean it's always executed correctly! Figured it was worth mentioning, at least. – Steven Schlansker Mar 09 '10 at 20:12
True, but in this case it was ;-) – Edward Shtern Mar 10 '10 at 16:59

Matt Solnit · Answer 3 · 2010-03-10T00:54:27.320

36

We have seen this same behavior in the past. It turned out that, for some crazy reason, if a NullPointerException occurred at the same place in the code multiple times, after a while using Log.error(String, Throwable) would stop including full stack traces.

Try looking further back in your log. You may find the culprit.

EDIT: this bug sounds relevant, but it was fixed so long ago it's probably not the cause.

edited Mar 10 '10 at 00:54

answered Mar 09 '10 at 23:26

Matt Solnit

32,152
8
53
57

3

The bug is closed, but the -XX:-OmitStackTraceInFastThrow flag is still needed to workaround the performance optimization. – Joshua Goldberg Jan 30 '12 at 22:09
I've been seeing this recently a lot. Any clues as to what might be causing this, or how to fix it? The logging system may have been up for days, and the actual cause rotated out, nevermind the tedious search... – Pawel Veselov Dec 14 '12 at 08:57
5

Pawel, have you tried the `-XX:-OmitStackTraceInFastThrow` JVM flag suggested by Joshua? See also http://stackoverflow.com/a/2070568/6198. – Matt Solnit Dec 14 '12 at 23:38
1

This was it for us. Thanks. – Andrew Cheong Nov 18 '19 at 19:24

Benoît Guérout · Answer 4 · 2011-10-14T21:37:14.403

24

Here is an explanation : Hotspot caused exceptions to lose their stack traces in production – and the fix

I've tested it on Mac OS X

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511)

Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)

Object string = "abcd";
int i = 0;
while (i < 12289) {
    i++;
    try {
        Integer a = (Integer) string;
    } catch (Exception e) {
        e.printStackTrace();
    }
}

For this specific fragment of code, 12288 iterations (+frequency?) seems to be the limit where JVM has decided to use preallocated exception...

edited Oct 14 '11 at 21:37

answered Oct 14 '11 at 20:58

Benoît Guérout

1,977
3
21
30

3

Wayback machine link: https://web.archive.org/web/20190911113910/http://jawspeak.com/2010/05/26/hotspot-caused-exceptions-to-lose-their-stack-traces-in-production-and-the-fix/ – aff Apr 19 '22 at 11:46

Peter Lang · Answer 5 · 2010-03-09T18:30:59.523

11

exception.toString does not give you the StackTrace, it only returns

a short description of this throwable. The result is the concatenation of:
* the name of the class of this object
* ": " (a colon and a space)
* the result of invoking this object's getLocalizedMessage() method

Use exception.printStackTrace instead to output the StackTrace.

edited Mar 09 '10 at 18:30

answered Mar 09 '10 at 18:25

Peter Lang

54,264
27
148
161

1

Sorry, I misspoke in my original post. I'm logging these through Log4J, which does use printStackTrace(). – Edward Shtern Mar 09 '10 at 18:34
1

Have you tried using `getStackTrace()` to make sure the problem is not with your logger? – Peter Lang Mar 09 '10 at 18:37
1

If you are using log4j, be sure to send the exception as part of the argument to the log method. I will post an answer with that. – Ravi Wallau Mar 09 '10 at 18:53
@raviaw valid point! @Edward Shtern: can you confirm that you definitely are using the 2-arg form of the log4j method? I know you mentioned in an answer further down that it is the company policy to do so, but are you ABSOLUTELY sure that in this case you are following the policy? – KarstenF Mar 09 '10 at 23:44
It might be a long shot, but is it possible that the exception originates in some 3rd party code? Maybe it is a (poorly written) exception wrapper, whose toString() simply returns the class name of the wrapped exception, and which fails to provide the underlying stack trace. Try put something like logger.info("Exception class = " + exc.class.getCanonicalName()) into your catch block and see what you get. – KarstenF Mar 10 '10 at 19:16

score 5 · Answer 6 · answered Mar 09 '10 at 20:14

Alternate suggestion - if you're using Eclipse, you could set a breakpoint on NullPointerException itself (in the Debug perspective, go to the "Breakpoints" tab and click on the little icon that has a ! in it)

Check both the "caught" and "uncaught" options - now when you trigger the NPE, you'll immediately breakpoint and you can then step through and see how exactly it is handled and why you're not getting a stack trace.

score 2 · Answer 7 · answered Aug 23 '22 at 04:32

VM stops outputting the stack trace of the exceptions which have been thrown a few times. This is a one of optimizations which happens in C2 compile.

According to the source code of OpenJDK, this optimization is applied to following exceptions:

-NullPointerException -ArithmeticException -ArrayIndexOutOfBoundsException -ArrayStoreException -ClassCastException

score 1 · Answer 8 · answered Mar 09 '10 at 18:27

1

toString() only returns the exception name and the optional message. I would suggest calling

exception.printStackTrace()

to dump the message, or if you need the gory details:

 StackTraceElement[] trace = exception.getStackTrace()

answered Mar 09 '10 at 18:27

Sheldon Young

29
1

See above - I misspoke - I am using printStackTrace(). – Edward Shtern Mar 09 '10 at 18:34

score 1 · Answer 9 · answered Mar 09 '10 at 18:31

This will output the Exception, use only to debug you should handle you exceptions better.

import java.io.PrintWriter;
import java.io.StringWriter;
    public static String getStackTrace(Throwable t)
    {
        StringWriter sw = new StringWriter();
        PrintWriter pw = new PrintWriter(sw, true);
        t.printStackTrace(pw);
        pw.flush();
        sw.flush();
        return sw.toString();
    }

Stephen C · Answer 10 · 2010-03-09T22:51:29.430

(Your question is still unclear on whether your code is calling printStackTrace() or this is being done by a logging handler.)

Here are some possible explanations about what might be happening:

The logger / handler being used has been configured to only output the exception's message string, not a full stack trace.
Your application (or some third-party library) is logging the exception using LOG.error(ex); rather than the 2-argument form of (for example) the log4j Logger method.
The message is coming from somewhere different to where you think it is; e.g. it is actually coming some third-party library method, or some random stuff left over from earlier attempts to debug.
The exception that is being logged has overloaded some methods to obscure the stacktrace. If that is the case, the exception won't be a genuine NullPointerException, but will be some custom subtype of NPE or even some unconnected exception.

I think that the last possible explanation is pretty unlikely, but people do at least contemplate doing this kind of thing to "prevent" reverse engineering. Of course it only really succeeds in making life difficult for honest developers.

score 1 · Answer 11 · answered Jun 07 '17 at 13:16

When you are using AspectJ in your project, it may happen that some aspect hides its portion of the stack trace. For example, today I had:

java.lang.NullPointerException:
  at com.company.product.MyTest.test(MyTest.java:37)

This stack trace was printed when running the test via Maven's surefire.

On the other hand, when running the test in IntelliJ, a different stack trace was printed:

java.lang.NullPointerException
  at com.company.product.library.ArgumentChecker.nonNull(ArgumentChecker.java:67)
  at ...
  at com.company.product.aspects.CheckArgumentsAspect.wrap(CheckArgumentsAspect.java:82)
  at ...
  at com.company.product.MyTest.test(MyTest.java:37)

NullPointerException in Java with no StackTrace

11 Answers11

Linked

Related