• Post Reply Bookmark Topic Watch Topic
  • New Topic

NullPointerException without stack trace  RSS feed

 
Philip Grove
Ranch Hand
Posts: 68
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I get notified (the system sends an email, and logs in a database) that an exception has occurred in our system, just to find that it was a NullPointerException without stack trace. I would love to find out what happened but without stack trace I am having a hard time tracking down the issue. I am looking for reasons for this to happen, I have seen reports related to performance optimizations but those reports are related to Java 1.4.2 and the issue should have been fixed with Java 1.5.0. I have given up trying to track down the exception and is trying to prevent it from happening again.

Our system runs as a servlet on Tomcat on a dedicated server.

"java -version" on the server output this version information:
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.9) (6b18-1.8.9-0.1~squeeze1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

We do use the log4j logger, but as the email is sent prior to logging it should be unaffected if that is causing any problems.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Then some code--either yours or in a library--is explicitly quashing the stack trace. Something like:

 
Philip Grove
Ranch Hand
Posts: 68
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In all my years of programming Java I have never seen this happen before, so a quick (I hope) follow up question.

I understand fully well that by catching Exception we have entered the realm of exception antipatterns, but why does it squash the stack trace?

Here is the way that I see it, please tell where my assumptions goes wrong.
NullPointerException is a subclass of RuntimeException which in turn is a subclass of Exception, so the NullPointerException is caught and long as nobody does anything to e other than read from it the information should remain unchanged. The only possibility I see is that if same thread throws another exception, but since execution of the try block ended the very moment the NullPointerException was thrown that does not seems possible. Other threads should have references to other Exception objects if something happens in them, so e should be unaffected by them.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Philip Grove wrote:In all my years of programming Java I have never seen this happen before, so a quick (I hope) follow up question.

I understand fully well that by catching Exception we have entered the realm of exception antipatterns, but why does it squash the stack trace?


A stack trace is only printed if somebody explicitly prints it. If an exception is totally uncaught, then the JVM prints the stack trace.




NullPointerException is a subclass of RuntimeException which in turn is a subclass of Exception,


Correct.

so the NullPointerException is caught and long as nobody does anything to e other than read from it the information should remain unchanged.


What "information"? You mean the stack trace held in the Exception? Right. That doesn't get changed. But that doesn't mean it magically gets printed. Somebody has to explicitly print it.
 
Philip Grove
Ranch Hand
Posts: 68
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The stack trace gets printed in both the email and the log entry and is just "NullPointerException" is both cases so something has destroyed the stack trace or it has never been anything else. In the case of the LogMailer by printing to a PrintWriter that wraps a StringWriter and then calling toString on the StringWriter, exactly how it happens in the Logger is a mystery because I do not know which method in invoked, and thus how it is handled but since the LogMailer gets invoked first I am pretty sure what the stack trace originally looks like. So it is not lost because nobody prints it, it appear to be lost because nobody sets it or somebody destroys it.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Philip Grove wrote:The stack trace gets printed in both the email and the log entry and is just "NullPointerException" is both cases


Then that's not a stack trace. That's just the exception's toString(). Did you study my code and its output?

So it is not lost because nobody prints it, it appear to be lost because nobody sets it or somebody destroys it.


That's probably either


or



Regardless, whatever is happening is because somebody wrote the Java code to do so. If you're lucky, it's in your code and you can fix it. If you're slightly less lucky, it's in 3rd party library code that you are allowed to modify. If you're much less lucky, it's in 3rd party library code that you're not allowed to modify, or in the Java API (though this last one seems very unlikely).
 
Philip Grove
Ranch Hand
Posts: 68
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:
Then that's not a stack trace. That's just the exception's toString(). Did you study my code and its output?


Then that's a bug somewhere in Java, or in the general understanding of how Java works. Because I know for certain that that is the result of calling printStackTrace on the instance of Exception.

I read your code, but studying it is pointless as it tells me nothing I didn't already know. I do know exception handling a everything that comes with it, this is just a case I have never seen before in my over 13 years of programming Java.
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This maybe related to a JIT compiler optimization that recompiles a method it throws a certain exception a couple of times. After recompilation the compiler can throw a pre-allocated exception, which naturally doesn't have the correct, or rahter any, strack trace.
Though this was a "bug" in the Hotspot server JVM, you seem to be using an Java 6 compatible IcedTea JVM. So I'm not sure if the same workaround applies to it, but for the hotspot VM there's a flag -XX:-OmitStackTraceInFastThrow that turns of the JIT optimization.
 
Philip Grove
Ranch Hand
Posts: 68
Firefox Browser Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jelle Klap wrote:This maybe related to a JIT compiler optimization that recompiles a method it throws a certain exception a couple of times. After recompilation the compiler can throw a pre-allocated exception, which naturally doesn't have the correct, or rahter any, strack trace.
Though this was a "bug" in the Hotspot server JVM, you seem to be using an Java 6 compatible IcedTea JVM. So I'm not sure if the same workaround applies to it, but for the hotspot VM there's a flag -XX:-OmitStackTraceInFastThrow that turns of the JIT optimization.


Reading through various pages on the internet I was lead to believe that this issue was in fixed in Java 5 and later.

I have been considering this case myself, but the NullPointerException in question was the first the system had thrown in several weeks, so pre-allocation seemed like a wasteful operation given as NullPointerExceptions are quite rare.
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not even going to attempt to guess why the JIT compiler does what it does and under what circumstances it decides to do it
If this was indeed the first occurance of the NPE then I don't see how the JIT compiler optimization would have come it to play here, which means I have no clue what else could be going on.
Though I'm not writing it off just yet, because although the fix added in the Java 5 Hotspot release would make the dissapearing stack trace issue at lot less frequent, they didn't remove the optimization alltogether.
In fact the release notes specifically point to the flag I mentioned earlier as a way to prevent it from occuring at all.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Philip Grove wrote:I know for certain that that is the result of calling printStackTrace on the instance of Exception.


I must have missed the part where you pointed that out earlier.

I read your code, but studying it is pointless as it tells me nothing I didn't already know. I do know exception handling a everything that comes with it


I have no way of knowing that. I went with Occam's Razor.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!