Request for Review 7158988: jvm crashes while debugging on x86_32 and x86_64.
vladimir.kozlov at oracle.com
Wed Apr 4 14:31:31 PDT 2012
I think it is good.
Coleen Phillimore wrote:
> I verified this bug and the fix, filed a bug and added the test to the
> repository. I put an SAP copyright on the test. I'm not sure if
> that's the right thing to do but I copied it from another test you
> added. Let me know if that's appropriate.
> commit comments:
> 7158988: jvm crashes while debugging on x86_32 and x86_64
> Summary: Object pointer is pushed more than once on stack, where GC
> doesn't expect it.
> Reviewed-by: coleenp
> Contributed-by: Axel.Siebenborn at sap.com
> We need other reviews, and then I'll check it in.
> Thank you for finding this bug and providing the fix and test case.
> On 4/3/2012 6:22 AM, Axel Siebenborn wrote:
>> Hi All,
>> we encountered a JVM crash while debugging a Java program under
>> load.We set a watch point to a variable using eclipse, so that the
>> watchpoint suspends just the thread. As a result, the jvm crashes with
>> a corrupted oop.
>> I attached two java files to reproduce the bug.
>> TestPostFieldModification starts two threads. One thread modifies the
>> String 'value'. The other thread triggers a GC periodically. In order
>> to reproduce, run the program in a debugger, set a modification watch
>> point for the field value and you should be able to crash the jvm.
>> The second java file I attached plays the part of the debugger to
>> reproduce the bug without eclipse.. The program launches a second jvm
>> via jdi and sets the watchpoint.
>> Command line:
>> $TEST_JDK/bin/java -cp $TEST_JDK/lib/tools.jar:. FieldMonitor
>> The problem is in the template table in jvmti_post_fast_field_mod().
>> At the entry of that function, the top of the java expression stack
>> (tos) is already popped to rax or xmm0. Before the call to
>> InterpreterRuntime::post_field_modification() the value is pushed back
>> to the stack.
>> A pointer to this value is passed as argument jvalue to the runtime
>> call. After pushing tos back to the stack, rax is pushed again to the
>> stack and rax is restored with that value.
>> This value will not be updated during a GC and rax will be restored
>> with a corrupted oop.
>> Another problem is that xmm0 will not be restored after the call.
>> False stack layout:
>> : :
>> | ... |
>> | rax | <- Top of expression stack updated by GC
>> | rax | <- another copy of rax, not updated by GC, used to restore
>> rax after call_VM()
>> Expected stack layout:
>> : :
>> | ... |
>> | rax | <- Top of expression stack, updated by GC, used to
>> restore rax after call_VM()
>> The following webrev suggests a fix:
>> The fix is based on the code on sparc, push tos values to the stack
>> and restore it after the call, so that the expression stack has the
>> expected layout and oops can be handled correctly during a GC.
More information about the hotspot-dev