How to read and understand the java stack trace?

Question

For example, I got a stack trace like this:

java.lang.NullPointerException
abc.investxa.presentation.controllers.UnixServerJobController.handleRequest(UnixServerJobController.java:66)
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)

So what is the root cause of this exception? From the stack trace, I found out that there is a problem with doFilter function in the OncePerRequestFilter class! However, when I put a break point there and the program never stop at that break point.

Could anyone give explanation about this!? And in general case, how should I use that stack case for debugging (read from bottom to top or from top to bottom)!

Solution 1

Generally the exact reason for the Exception is at the first line of your Stack Trace, and for more information about the cause of that exception, you need to gradually move down, and the root cause can often be found somewhere near the bottom of the stack trace.

But in most cases, you can even get the cause of the exception from the first few lines..

So, in this case, your exception is at handleRequest method, and when you move downwards, those are the methods, which invoked your previous method (The one at above the current method in stack trace)

Solution 2

You should generally read from the top - so in this case, there's a NullPointerException at line 66 of UnixServerJobController, in the handleRequest method. That method was called by SimpleControllerHandlerAdapter.handle, which was called by DispatcherServlet.doDispatch etc.

However, in this particular case it's likely that the first frame of the stack trace is all you need. Look at line 66 of UnixServerJobController, work out what might be null, and act accordingly.

Note that sometimes one exception is wrapped in another (which may in turn be wrapped in another, etc). In this case you should look at each of the stack traces - often it's the "most nested" exception which gives the most useful information, as that's the root cause.

Solution 3

This tutorial might shed some light on your problem and help you understand things better.

As per your problem, you seem to have a Null Pointer Exception at line 66 of the Unix Server Job Controller class.

Solution 4

I found this tutorial is highly useful to me https://forums.bukkit.org/threads/how-to-read-stack-traces-and-troubleshoot-your-own-plugins-by-yourself.32457/

View more solutions

Comments

[John Dvorak]

"it's likely that the first frame of the stack trace is all you need" unless the exception is thrown by a library because you supplied the wrong set of parameters.

[Rohit Jain]

Can the down voter comment on where I'm wrong??

[Tomasz Nurkiewicz]

When exceptions are wrapped and rethrown, the import line is hidden in the middle

[Toby D]

Oh great, this tutorial is what I'm seeking for, thanks :D

[John Dvorak]

In enterprise java, the bottom of the call stack is often a library function, and not worthwhile investigating.

[Rohit Jain]

@JanDvorak.. May be that it is not often required to investigate that, but it is the root cause right?? So, where I'm wrong in saying that??

[Jon Skeet]

@JanDvorak: I was referring to this particular stack trace - will make that clearer.

[Jon Skeet]

@TomaszNurkiewicz: Yes, will add information about that, too.

[John Dvorak]

If you want to get blamed for the mistakes of all your employees, then yes, the library is at fault :-)

[Rohit Jain]

@JanDvorak.. Ok. that I consider.. I've edited the post to say - somewhere near bottom.. Can it be justified in your case??

[Toby D]

Hi Jon, I have always admired you. It's great when having you answered my question. :D

[Rohit Jain]

@JanDvorak.. If my modified post looks OK, can you toggle your vote.. Or, I would like you to explain a little bit more, so that I can understand it better and be more clear..

[John Dvorak]

As you can see from the stack trace, there are nine stack frames from the library, and only the top frame is a user function (and likely to blame). This is often the case that the cause is near the top.

[Rohit Jain]

@JanDvorak OK.. Thanks for explanation..

[John Dvorak]

"is near the bottom" is not true. "is often near the bottom" may be diputed. "can be near the bottom" is certainly true, but does not tell much.

[John Dvorak]

Your answer still claims doFilter is to blame. It most certainly isn't.

[Rohit Jain]

@JanDvorak.. Thanks Jan.. I've edited my post accordingly..

[John Dvorak]

The last paragraph doesn't make much sense. Retracted anyways ;-)

[Jon Skeet]

This is basically a link-only answer, which is almost never a good idea. (It becomes utterly useless if the linked page is removed, for example.) You should at least quote the most important parts of the post.

[Drazen Bjelovuk]

By "most nested", do you mean the one furthest down the list?

[Jon Skeet]

@JoshBjelovuk: Yes - the one that actually caused it all.

[Elio]

Here is also a very usefull link to understand how to read the stack trace from an exception: nurkiewicz.com/2011/09/logging-exceptions-root-cause-first.h‌​tml