JDK-4808151 : crash in AsyncGetCallTrace() when invoked during Deoptimization
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: k2_ea2,1.4.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-01-24
  • Updated: 2003-07-18
  • 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 :  
JDK-4861744 - Java AsyncGetCallTrace() core dump using libcollector on S1AS7
Relates :  
JDK-4762958 - occasional crashes/deadlocks from AsyncGetCallTrace()
Description
When a method is being deoptimized, its callstack can not be safely
walked by AsyncGetCallTrace().
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-02-19 At first glance, the DeoptimizationMarker object appears to provide the flag needed to prevent AsyncGetCallTrace() from walking a stack that is in the process of being deoptimized. DeoptimizationMarker objects set a global flag during several deopt related calls: VM_Deoptimize VM_DeoptimizeFrame VM_DeoptimizeAll Universe::flush_dependents_on_method() Universe::flush_evol_dependents_on() However, Deoptimization::unpack_frames() does not create any DeoptimizationMarker objects so the flag is not necessarily set during the unpack_frames() call. ###@###.### 2003-03-12 All of the stack traces listed in the comments section show code that executes from the deoptimization handler. I experimented with just protecting the unpack_frames() call, but that is insufficient. The deoptimization handler itself creates temporary frames in preparation for unpack_frames(). AsyncGetCallTrace() can also get confused by the temporary frames. It looks like marking the thread as being in the deoptimization handler is the safest thing to do. AsyncGetCallTrace() can detect the new condition and bail out.
11-06-2004
PUBLIC COMMENTS crash in AsyncGetCallTrace() when invoked during Deoptimization
10-06-2004