JDK-6519092 : (thread) Thread.getStrackTrace() returns different results on jdk5.0 and jdk6
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-01-30
  • Updated: 2011-02-16
  • Resolved: 2007-03-08
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

and

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
MS Windows XP SP 2

A DESCRIPTION OF THE PROBLEM :
The method Thread.getStackTrace() returns different results when executed on JDK  1.5 and JDK 1.6.

on JDK1.6 the stacktrace starts with the element
[0] "java.lang.Thread.getStackTrace(Thread.java:1426)"
...

on JDK1.5 the stacktrace starts with a different element
[0] "java.lang.Thread.dumpThreads(Native Method)"
[1] "java.lang.Thread.getStackTrace(Thread.java:1383)"
....

I think the problem is introduced with the lines

	    // Don't need JVM help for current thread
	    return (new Exception()).getStackTrace();

that are new in JDK 1.6 version of Thread.getStackTrace(). Seems like Throwable.getStackTrace() and dumpThreads return different results.

REPRODUCIBILITY :
This bug can be reproduced always.

Comments
EVALUATION This evaluation is seconded.
08-03-2007

EVALUATION As the bug description indicates, the change in the returned array of StrackTraceElements is due to a change in the implemention. Since the currently returned value accurately reflects the state of the stack for the current thread and the specification makes no guarantees regarding the internal implementation of the method, I am inclined to close this issue as "not a bug".
30-01-2007