Request for Review 7158988: jvm crashes while debugging on x86_32 and x86_64.

[Vladimir Kozlov]

I think it is good.

Vladimir

Coleen Phillimore wrote:
> 
> Axel,
> 
> 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.
> 
> http://cr.openjdk.java.net/~coleenp/7158988/
> http://bugs.sun.com/view_bug.do?bug_id=7158988
> 
> 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.
> Coleen
> 
> 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:
>>
>> http://sapjvm.com/as/webrevs/post_field_modification/
>>
>> 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.
>>
>> Regards,
>> Axel
>>
>>
>>
>>