Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7158988

jvm crashes while debugging on x86_32 and x86_64

    Details

    • Subcomponent:
    • Resolved In Build:
      b08
    • CPU:
      generic, x86
    • OS:
      generic, os_x
    • Verification:
      Verified

      Backports

        Description

        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

          Issue Links

            Activity

            Show
            jprtbugupd JPRT Bug Updates (Inactive) added a comment - BT2:EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/19e197e2a1af
            Show
            jprtbugupd JPRT Bug Updates (Inactive) added a comment - BT2:EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/19e197e2a1af
            Show
            jprtbugupd JPRT Bug Updates (Inactive) added a comment - BT2:EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/19e197e2a1af
            Hide
            kzhaldyb Kirill Zhaldybin (Inactive) added a comment -
            RULE runtime/7158988/FieldMonitor.java Crash SIGSEGV
            Show
            kzhaldyb Kirill Zhaldybin (Inactive) added a comment - RULE runtime/7158988/FieldMonitor.java Crash SIGSEGV
            Hide
            kzhaldyb Kirill Zhaldybin (Inactive) added a comment -
            RULE runtime/7158988/FieldMonitor.java Crash EXCEPTION_ACCESS_VIOLATION
            Show
            kzhaldyb Kirill Zhaldybin (Inactive) added a comment - RULE runtime/7158988/FieldMonitor.java Crash EXCEPTION_ACCESS_VIOLATION

              People

              • Assignee:
                ctornqvi Christian Tornqvist
                Reporter:
                coleenp Coleen Phillimore
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: