United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6445945 Unexpected exception: "java.lang.InternalError: Location with invalid code index"
JDK-6445945 : Unexpected exception: "java.lang.InternalError: Location with invalid code index"

Details
Type:
Bug
Submit Date:
2006-07-03
Status:
Resolved
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2007-03-15
Component:
hotspot
OS:
generic
Sub-Component:
jvmti
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6,6u2
Fixed Versions:
hs10 (b10)

Related Reports
Backport:
Backport:

Sub Tasks

Description
Test description:
Debugger forces debuggee start test thread which in infinite loop call method which should be inlined. Debugger obtains ThreadReference  for test thread, suspend it and call forceEarlyReturn() and also debugger checks that MethodExitEvent is generated for interrupted method. 

When debugger receives MethodExitEvent event it try to print event data, but MethodExitEvent.location().lineNumber() throws InternalError and MethodExitEvent.location().codeIndex() returns strange negative value.

Bug isn't reproducible on sparc machines.

Test output:

debuggee out>>>Command received: StartTestThread
Method testMethod
Code index -1045171372
Unexpected exception: 
java.lang.InternalError: Location with invalid code index
	at com.sun.tools.jdi.ConcreteMethodImpl.codeIndexToLineInfo(ConcreteMethodImpl.java:167)
	at com.sun.tools.jdi.LocationImpl.getBaseLineInfo(LocationImpl.java:108)
	at com.sun.tools.jdi.LocationImpl.getLineInfo(LocationImpl.java:122)
	at com.sun.tools.jdi.LocationImpl.lineNumber(LocationImpl.java:199)
	at com.sun.tools.jdi.LocationImpl.lineNumber(LocationImpl.java:195)
	at com.sun.tools.jdi.LocationImpl.lineNumber(LocationImpl.java:191)
	at MethodExitEventTest.main(MethodExitEventTest.java:359)
debuggee out>>>Command received: QUIT
debuggee out>>>Exit
TEST FAIL

                                    

Comments
EVALUATION

I tried the fastdebug version of jvm crashes at this location.

Current thread (0x081dac00):  JavaThread "TestThread" [_thread_in_vm, id=6510]

Stack: [0xac35e000,0xac3af000),  sp=0xac3adabc,  free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x8f4fa8];;  _ZN7VMError14report_and_dieEv+0x258
V  [libjvm.so+0x4059a5];;  _Z24report_assertion_failurePKciS0_+0x55
V  [libjvm.so+0x73a185];;  _ZNK13methodOopDesc8bci_fromEPh+0x65
V  [libjvm.so+0x8eb806];;  _ZNK17interpretedVFrame3bciEv+0x36
V  [libjvm.so+0x65e9d9];;  _ZN12JvmtiEnvBase18get_frame_locationEP10JavaThreadiPP10_jmethodIDPx+0x2f9
V  [libjvm.so+0x65363f];;  _ZN8JvmtiEnv16GetFrameLocationEP10JavaThreadiPP10_jmethodIDPx+0x3f
V  [libjvm.so+0x5dc3f8];;  jvmti_GetFrameLocation+0x258
C  [libjdwp.so+0x20ab3];;  handleFrameEvent+0x53
C  [libjdwp.so+0x16293];;  event_callback+0x183
C  [libjdwp.so+0x18629];;  cbMethodExit+0x139
V  [libjvm.so+0x66b439];;  _ZN11JvmtiExport16post_method_exitEP10JavaThreadP13methodOopDesc5frame+0x6a9
V  [libjvm.so+0x4ebdf4];;  _ZN18InterpreterRuntime16post_method_exitEP10JavaThread+0x174
j  MethodExitEventTest_Debuggee.testMethod()I
[error occurred during error reporting, step 120, id 0xe0000000]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

After force early return the bcp address for the frame has bad value.

-Swamy
                                     
2006-07-12
EVALUATION

Serguei looked at this and he wrote:
>ForceEarlyReturn does nothing special with bcp.
>The MethodExit event is posted in the middle of
>ForceEarlyReturn so there can be some inconsistency
>in the frame state which needs to be investigated.
>The ForceEarlyReturn follows the PopFrame code path
>pattern which does not need to post this event. 
--------------------------------------------------

Anyway we know the bcp is bad and we need more time
to investigate the exact cause so we are deferring
this to mustang update release.

-Swamy
                                     
2006-07-17
EVALUATION

This is a ForceEarlyReturn implementation bug specific to x86 and amd64.
It happens when the following three conditions take place:
  - the top frame deoptimization is triggered by the ForceEarlyReturn
  - the method_exit event is enabled
  - a method_exit event handler invokes the JVMTI GetFrameLocation()

The problem is that the register state is not restored in the
generate_earlyret_entry_for after the top frame is deoptimized.
As a result, the bcp is broken, and the fastdebug VM crashes with the assertion:

#debugee.stdout> # To suppress the following error report, specify this argument
#debugee.stdout> # after -XX: or in .hotspotrc:  SuppressErrorAt=/methodOop.cpp:151
#debugee.stdout> #
#debugee.stdout> # An unexpected error has been detected by Java Runtime Environment:
#debugee.stdout> #
#debugee.stdout> #  Internal Error (/net/prt-solx86-q1-2/PrtBuildDir/workspace/src/share/vm/oops/methodOop.cpp, 151), pid=25765, tid=13
#debugee.stdout> #
#debugee.stdout> # Java VM: Java HotSpot(TM) Client VM (20061103204827.dcubed.service_hs_b02_merge.6-debug compiled mode)
#debugee.stdout> #
#debugee.stdout> # Error: assert(is_native() && bcp == code_base() || contains(bcp),"bcp doesn't belong to this method")
#debugee.stdout> # An error report file with more information is saved as hs_err_pid25765.log

Please, see full hs_err_pid25765.log in the bug comments.
                                     
2007-02-20
SUGGESTED FIX

This is a ForceEarlyReturn implementation bug specific to x86 and amd64.
  It happens when the following three conditions take place:
   - the top frame deoptimization is triggered by the ForceEarlyReturn
   - the method_exit event is enabled
   - a method_exit event handler invokes the JVMTI GetFrameLocation()
The problem is that the register state is not restored in the
generate_earlyret_entry_for after the top frame is deoptimized.
As a result, the bcp is broken, so the fastdebug VM crashes with the assertion in
the methodOopDesc:bci_from(int bcp) [src/share/vm/oops/methodOop.cpp, 151]:
  assert(is_native() && bcp == code_base() || contains(bcp),"bcp doesn't belong to this method")

Solution:
  To always restore the register state like this:
    __ restore_bcp();
    __ restore_locals();

Please, see the suggested fix webrev hs_eret7.Feb22.tar.gz in the CR attachments.
                                     
2007-02-21



Hardware and Software, Engineered to Work Together