Infinite Looping code and jstack
Thomas.Rodriguez at Sun.COM
Thu Mar 20 10:27:04 PDT 2008
I believe that jstack may induce a safepoint in the target VM so the
stack trace will always occur at safepoints in the code. This might
cause the trace to tend to point at a particular locations. A trick
that might work is to gcore the process and use jstack on that. That
assumes your cores aren't huge though.
If you are on s10 or later, pstack on s10 will decode Java stack traces
though there are sometimes issues with getting full traces. It's pretty
good at the top of the stack though which is where you're interested.
What platform are you on?
Scott Oaks wrote:
> We have an appserver installation where some set of threads get into an
> infinite loop. jstack always reports that the threads in question are at
> a specific line.
> Here's a snippet of the jstack output:
> "http80-Processor584" daemon prio=10 tid=0x015af400 nid=0x8d4 runnable
> java.lang.Thread.State: RUNNABLE
> parseHeader (line 805) isn't really a loop at all; there's no way I can
> account for the infinite loop being in that method. It's conceivable
> somehow that parseHeaders (line 607) could be in a loop:
> while (parseHeader())
> But in that case, wouldn't I get somewhat differing results from
> successive invocations jstack (or even one jstack where multiple threads
> are in the same method)?
> I guess what I'm really asking is what the granularity of jstack is --
> if I were in an infinite loop over two methods and 40-50 lines of code,
> is it really conceivable that jstack would always show me I was on the
> very same line (because that line corresponds to a safepoint or
> something)? Or is something else more likely going on?
> This is with JDK 1.6.0_02 and the server compiler.
More information about the hotspot-dev