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


                                     

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.

                                     

PUBLIC COMMENTS

crash in AsyncGetCallTrace() when invoked during Deoptimization