JDK-6583275 : Hotspot crash in vm_perform_shutdown_actions due to uninitialized TLS during out of memory handling
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2007-07-20
  • Updated: 2011-04-23
  • Resolved: 2011-04-23
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.
JDK 6 JDK 7 Other
6u25Fixed 7Fixed hs20Fixed
Description
The VM crashes on the way to reporting an out of memory condition.  This happens during thread creation, before TLS is initialized.  It could be a missing NULL check in vm_perform_shutdown_actions() after a call to Thread::current().  ###@###.### suggested that vm_perform_shutdown_actions() should probably use TLS:get_thread_slow().
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0eb90baf1b69
08-01-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0eb90baf1b69
07-01-2011
EVALUATION I believe the crash stack pointed out in the comments section comes from Linux platform. The root cause of the crash is the Thread object getting from Thread::current() call is NULL since the fast path for retrieving the Thread object from the internal array (caching the known Thread objects) fails. To be a little bit more in detail, there is a array used internally for caching the Thread objects created. The array index for these Thread object is carefully choosen. There might be crash before inserting the Thread object into that array and as a result, it might cause The fast path of retrieving the Thread object to return NULL. As a good practice, in the possible VM exit path, we should program defensively to consider that possibility. So the fix would be as simple as falling back to slow path when Thread returned from Thread::current is NULL.
01-11-2007