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

~ThreadInVMForHandshake() should call handle_special_runtime_exit_condition()

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      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

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

                  Dates

                  Created:
                  Updated:
                  Resolved: