Infinite Looping code and jstack

[Tom Rodriguez]

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?

tom

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
> [0x26bdf000..0x26bdf9f0]
>    java.lang.Thread.State: RUNNABLE
>         at
> org.apache.coyote.http11.InternalInputBuffer.parseHeader(InternalInputBuffer.java:805)
>         at
> org.apache.coyote.http11.InternalInputBuffer.parseHeaders(InternalInputBuffer.java:607)
>         at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:667)
> 
> 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())
>           doSomething
> 
> 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.
> 
> -Scott
>