jason, Out of personal interest I have a question about the way you use jstack. I came across this "jstack cannot take dump of hung process" problem before. I once witnessed the same exceptions when chasing a deadlock.
This happened to me on ubuntu 10.4.0 (and 10.4.1) 64-bit using sun's jdk 1.6.0_21 My mistake was to invoke jstack as a different user, that is, not the user which is running the given java application (e.g. root instead of tomcat6). Invoking jstack with the -F option as root showed these exceptions, whereas kill -QUIT didn't produce anything and jstack without -F failed as well. As a quick workaround I changed /etc/passwd to allow the user tomcat6 to use a shell. Issuing a "su tomcat6" as root I was able to get jstack (and kill -QUIT) working. Disclaimer: I don't know how tomcat is packaged for Red Hat. I tried to check this with so. who actually claimed that his jvm was hung when he tried to get a stack-trace. However, I was told that the problem no longer exists (no hung jvm anymore) and the investigation ceased. This is were you come into play :) It appears to me that "hung application" alone does not imply that "-F" is required. So, if my application enters a infinite loop or gets stuck in a deadlock my application is unresponsive and will most likely be referred to as "hung", but the vm is actually functioning perfectly. It's just my application, that, well, . . . . In my case I was able to get a stacktrace from an application which was stuck in a deadlock (log4j with multiple appenders, multiple threads using the same Logger instance) without using "-F" at all. When you use jvisualvm you most likely do so by enabling (and connecting through) jmx (true?). I believe it's correct to claim that this is at least a different way of attaching to the vm, than using jstack from the comandline. Could be the reason why you were "suddenly" able to get a thread dump. Could you give it a shot? Best Regards, Martin
