JDK-4850081 : Get/SetThreadLocalStorage need to work with AsyncGetCallTrace
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 1.4.0,1.4.1,1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,solaris,windows_nt
  • CPU: x86,sparc
  • Submitted: 2003-04-17
  • Updated: 2012-10-10
  • Resolved: 2003-06-05
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
1.4.2_02 02Fixed
Related Reports
Duplicate :  
Description
###@###.### 2003-04-17

AsyncGetCallTrace() is called from a SIGPROF signal handler and provides
a data buffer into which call frames are stored. A per-thread call frame
buffer could be attached to thread local storage to ease implementation
of the SIGPROF signal handler.

There are a couple of issues with using JVM/PI GetThreadLocalStorage()
and SetThreadLocalStorage() in a signal handler:

- the methods are currently JVMPI_ENTRY() points and indirectly use a
  HandleMarkCleaner. The HandleMarkCleaner finds the lowest HandleMark
  on the stack and cleans up the Handles to that point. When called
  from a SIGPROF signal handler, this causes random Handles to be
  cleaned up. This results in strange hangs and crashes due to objects
  being unlocked, freed, and overwritten. In short, carnage ensues.
- the methods do not check the return value from
  JavaThread::thread_from_jni_environment() before using it. This means
  that toward the end of a thread's life, a NULL pointer dereference
  can crash the VM.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_02 tiger FIXED IN: 1.4.2_02 tiger INTEGRATED IN: 1.4.2_02 tiger tiger-b08
14-06-2004

EVALUATION ###@###.### 2003-04-17 There are other APIs that don't check the return value from JavaThread::thread_from_jni_environment() before using it. However, this bug fix is targetted for a Mantis-Update release so we should minimize the changes. Changing GetThreadLocalStorage() and SetThreadLocalStorage() from JVMPI_ENTRY() to JVMPI_RAW_ENTRY() means these APIs will not stop for a safepoint via the ThreadInVMFromUnknown object. However, since these methods only return or set thread local storage that isn't really a problem.
11-06-2004

PUBLIC COMMENTS .
10-06-2004