JDK-5057116 : EXECUTION STOPPED: on return to interpreted call, restored SP is corrupted
Type:Bug
Component:hotspot
Sub-Component:runtime
Affected Version:5.0
Priority:P3
Status:Closed
Resolution:Fixed
OS:solaris_9
CPU:sparc
Submitted:2004-06-03
Updated:2012-10-08
Resolved:2004-06-15
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.
SUGGESTED FIX
interfaceSupport.hpp:
// Another special case for nmethod_entry_point so the nmethod that the
// interpreter is about to branch to doesn't get flushed before as we
// branch to it's interpreter_entry_point. Skip stress testing here too.
+ // Also we don't allow async exceptions because it is just too painful.
#define IRT_ENTRY_FOR_NMETHOD(result_type, header) result_type header { nmethodLocker _nmlock(nm); ! ThreadInVMfromJavaNoAsyncException __tiv(thread); __ENTRY(result_type, header, thread)
#define IRT_END }
18-08-2004
EVALUATION
This is caused by posting an async exception during the interpreter
runtime entry point: InterpreterRuntime::nmethod_entry_point().
This is an especially troublsome entry point because we look to be
be called from the interpreter because of the return pc but the
frame can be a call_stub, c2i, or interpreter frame. If it is
a call_stub when the async exception is installed we will unwind the
frame improperly and corrupt the SP.
###@###.### 2004-06-03