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

~ThreadInVMForHandshake() should call handle_special_runtime_exit_condition()

    XMLWordPrintable

Details

    • b22

    Backports

      Description

        A java thread T potentially continues execution after it was suspended by a JVMTI agent during the
        attempt to process a handshake operation. This can lead to undefined behaviour and crashes.

        Problematic execution sequence:

        - Handshake operation H is executed for java thread T
        - T calls ThreadSafepointState::handle_polling_page_exception()
        - T arrives in HandshakeState::process_self_inner()
        - T transitions from _thread_in_Java to _thread_in_vm
        - but too late: the VM thread already claimed H
        - T calls _semaphore.wait_with_safepoint_check()
        - T transitions from _thread_in_vm to _thread_blocked
        - The VM thread completes H and calls _semaphore.signal()
        - Before T can transition back to _thread_in_vm, the VM thread schedules another safepoint and
          executes VM_ThreadSuspend on behalf of a JVMTI agent that wants to suspend T
        - After the safepoint T transitions back to _thread_in_vm and then to _thread_in_Java.
        - T continues executing an undefined number of bytecodes ...

        Similar if T returns from a native method call.

        The VM could crash because of this, e.g. because T's stack is not walkable after the suspend.

        Attachments

          Issue Links

            Activity

              People

                rrich Richard Reingruber
                rrich Richard Reingruber
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: