JDK-6503017 : assert(fr().is_deoptimized_frame(),"frame must be scheduled for deoptimization")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2006-12-11
  • Updated: 2010-04-02
  • Resolved: 2007-01-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.
JDK 6 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
Description
Nightly test of this test 

nsk.jdwp.StackFrame.SetValues.setvalues001

failed after patchless deopt was putback.
From the putback comment:

This was caused by patchless deopt. Basically when the setvalue code is used
for a compiled frame it deopts it so that the debuggers can see (and set) the
locals in the interpreter frame. The assert fired because the compiled vframe
was the the frame before the deopt occurred. The code actually worked fine but
the assert I put in to be sure that we deopted before trying to set the values
fired. The fix is to re-read the frame after the deopt is scheduled.
Comments
EVALUATION From the putback comment: This was caused by patchless deopt. Basically when the setvalue code is used for a compiled frame it deopts it so that the debuggers can see (and set) the locals in the interpreter frame. The assert fired because the compiled vframe was the the frame before the deopt occurred. The code actually worked fine but the assert I put in to be sure that we deopted before trying to set the values fired. The fix is to re-read the frame after the deopt is scheduled.
17-01-2007