Bug 1095504

Summary:	jstack - Unable to deduce type of thread from address" and "sun.jvm.hotspot.utilities.AssertionFailure"
Product:	[Fedora] Fedora	Reporter:	Thomas Meyer <thomas.mey>
Component:	java-1.7.0-openjdk	Assignee:	Deepak Bhole <dbhole>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	ahughes, dbhole, jerboaa, jvanek, omajid, sgehwolf, thomas.mey
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-05-16 21:33:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Thomas Meyer 2014-05-07 21:24:11 UTC

Description of problem:

There seems to be two problems:

1.) java.lang.RuntimeException: Unable to deduce type of thread from address
-> from call of DeadlockDetector.print(tty); in 
source/jdk7/hotspot/agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java

2.) A
-> from instantation of new ConcurrentLocksPrinter(); also in
source/jdk7/hotspot/agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java

Output:

jstack -F -l 3971
Attaching to process ID 3971, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.51-b03
Deadlock Detection:

java.lang.RuntimeException: Unable to deduce type of thread from address 0x00007fd45801d000 (expected type JavaThread, CompilerThread, ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
	at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:162)
	at sun.jvm.hotspot.runtime.Threads.first(Threads.java:150)
	at sun.jvm.hotspot.runtime.DeadlockDetector.createThreadTable(DeadlockDetector.java:149)
	at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:56)
	at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
	at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52)
	at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
	at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
	at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
	at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
	at sun.tools.jstack.JStack.main(JStack.java:102)
Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x00007fd45801d000
	at sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
	at sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
	at sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:158)
	... 15 more
Can't print deadlocks:Unable to deduce type of thread from address 0x00007fd45801d000 (expected type JavaThread, CompilerThread, ServiceThread, JvmtiAgentThread, or SurrogateLockerThread)
Exception in thread "main" java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
	at sun.tools.jstack.JStack.main(JStack.java:102)
Caused by: sun.jvm.hotspot.utilities.AssertionFailure: Expecting GenCollectedHeap, G1CollectedHeap, or ParallelScavengeHeap, but got sun.jvm.hotspot.gc_interface.CollectedHeap
	at sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
	at sun.jvm.hotspot.oops.ObjectHeap.collectLiveRegions(ObjectHeap.java:604)
	at sun.jvm.hotspot.oops.ObjectHeap.iterateSubtypes(ObjectHeap.java:417)
	at sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:260)
	at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.fillLocks(ConcurrentLocksPrinter.java:70)
	at sun.jvm.hotspot.runtime.ConcurrentLocksPrinter.<init>(ConcurrentLocksPrinter.java:36)
	at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:61)
	at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
	at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
	at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
	at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
	... 6 more


Version-Release number of selected component (if applicable):
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.x86_64/bin/jstack


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Severin Gehwolf 2014-05-09 09:03:29 UTC

I can confirm this. It's reproducible by running jstack on any java process (printed by jps):
$ /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.x86_64/bin/jstack -F -l <pid>

Same result before and after installing the *-debuginfo package.

Comment 2 Severin Gehwolf 2014-05-09 10:58:46 UTC

From "man jstack" I see this for the -F option:

 -F Force a stack dump when 'jstack [-l] pid' does not respond.

On a healthy process I can reproduce your problem by using '-F'. Though, "jstack -l <pid>" works fine for the process I try this on. Thomas, does "jstack -l <pid>" work for your process? Do you have to use '-F'?

Comment 3 Thomas Meyer 2014-05-09 19:43:40 UTC

I tried to get a jstack trace in a busy jetty webserver. I tried without -F but jstack wasn't able to connect to the busy Java process, so I used the -F option.

Comment 4 Deepak Bhole 2014-05-14 17:51:14 UTC

Are you running jmap -F as the same user who owns the process?

Comment 5 Thomas Meyer 2014-05-15 18:00:02 UTC

No, I did run jstack as root and not as user jetty. Running jstack with user jetty works correctly!!

Opps! A better error message would be a good thing...

Thanks and sorry for the noise!

Comment 6 Deepak Bhole 2014-05-16 21:33:55 UTC

Perfect! Okay, I am going to close this. I think sometimes jstack does work as root but not always, unfortunately. Always best to do it as same user to be on the safe side :)