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

[Axel Siebenborn]

Hi Coleen,
thanks for filing the bug and creating the webrev. The copyright on the 
test is ok.
However, unless the output of the test is not checked, the test will 
never fail.
I would suggest to grep for a string contained in the error message and 
attach the
output of the failing VM to the test output if the test really fails:

grep "A fatal error has been detected" test.out > ${NULL}
if [ $? = 0 ]; then
     cat test.out
     STATUS=1
fi

Thanks,
Axel


On 4/4/2012 8:07 PM, 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
>>
>>
>>
>>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestFieldMonitor.sh
Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120405/b7c064bc/TestFieldMonitor.sh