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

[Coleen Phillimore]

I think the status is nonzero if the test crashes, but I made your 
suggested change.
Thanks!
Coleen

On 4/5/2012 5:26 AM, Axel Siebenborn wrote:
> 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
>>>
>>>
>>>
>>>
>