JDK-8223572 : ~ThreadInVMForHandshake() should call handle_special_runtime_exit_condition()
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 11,13
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- Submitted: 2019-05-08
- Updated: 2020-10-13
- Resolved: 2019-05-16
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 11 | JDK 13 |
|---|---|
| 11.0.5Fixed | 13 b22Fixed  |
Related Reports
|
Relates :
|
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.
Comments
|