JDK-2156937 : (thread) Thread.getStackTrace() returns null
  • Type: Backport
  • Backport of: JDK-6571589
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2007-12-07
  • Updated: 2011-02-16
  • Resolved: 2009-02-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 7
5.0u17-rev b09Fixed 7Fixed
Description
Please read the note of Parent CR.
1. Did we fix the underlying problem? yes.
2. Should we consider any of the follow-on items:
 better product documentation: N
 better serviceability tools: N
 new/improved tests: N
Comments
EVALUATION The problem here is that there is a race between the thread calling getStackTrace and the thread, on which the stacktrace is trying to be retrieved, terminating. The library code for getStackTrace calls isAlive to determine if the thread is alive before calling into the vm to retrieve its stacktrace. Of course the thread may be alive at this point and subsequently terminate before the vm tries to retrieve its stacktrace. Looking at the vm operation VM_ThreadDump it looks this this code quite rightly handles threads that have terminated or are exiting, by adding a ThreadSnapshot that has a NULL _stack_trace. The problem or area of contention seems to be that ThreadService::dump_stack_traces when it sees a NULL stacktrace in one of the snapshots it puts a NULL into the StackTraceElement[][] instead of possibly an empty StackTraceElement[] element. The library code is not expecting this null. ..or is it. Thread.getAllStackTraces already tests for a possible null element in the StackTraceElement[][] returned from JVM_DumpThreads. So that being said I have amended the library code to handle this situation.
07-12-2007