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

[Coleen Phillimore]

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
>
>
>
>