JDK-8352180 : AttachListenerThread causes many tests to timeout on Windows
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 25
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2025-03-17
  • Updated: 2025-05-07
  • Resolved: 2025-03-18
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.
JDK 25
25 b15Fixed
Related Reports
Causes :  
Causes :  
Description
JDK-8319055 added the use of the  FlushFileBuffers call when closing the pipe on Windows. That call will block until all of the data has been read from the other end of the pipe. The AttachListenerThread is executing in state _thread_in_vm when it does this and so is not safepoint-safe. This prevents a safepoint (or many safepoints) from being reached in a timely manner and the test time out.

Here's a sample stacktrace from a failing test:

The MainThread is executing a VM op:

  18  Id: 5acc.8c48 Suspend: 13 Teb: 0000009f`e1505000 Unfrozen "MainThread"
 # Child-SP          RetAddr               Call Site
00 0000009f`e2bfb7b8 00007fff`3d083b2b     ntdll!ZwWaitForAlertByThreadId+0x14
01 0000009f`e2bfb7c0 00007fff`3ab6de58     ntdll!RtlSleepConditionVariableCS+0x14b
02 0000009f`e2bfb830 00007fff`12a1fbad     KERNELBASE!SleepConditionVariableCS+0x38
03 0000009f`e2bfb860 00007fff`129b3a49     jvm!PlatformMonitor::wait(
			unsigned int64 millis = 0)+0x3d
04 0000009f`e2bfb8a0 00007fff`12d078b3     jvm!Monitor::wait(
			unsigned int64 timeout = 0)+0x169
05 (Inline Function) --------`--------     jvm!MonitorLocker::wait(void)+0xe
06 (Inline Function) --------`--------     jvm!VMThread::wait_until_executed(void)+0x131
07 0000009f`e2bfb900 00007fff`1250f43f     jvm!VMThread::execute(
			class VM_Operation * op = 0x0000009f`e2bfb9c0)+0x1f3
08 (Inline Function) --------`--------     jvm!InterfaceSupport::deoptimizeAll(void)+0x62
09 0000009f`e2bfb990 00007fff`12b1fee5     jvm!VMEntryWrapper::~VMEntryWrapper(void)+0x1cf
0a 0000009f`e2bfe220 00000219`dd657b66     jvm!SharedRuntime::resolve_opt_virtual_call_C(
			class JavaThread * current = 0x00000219`c1080370)+0x1c5
0b 0000009f`e2bfe290 00000219`c1080370     0x00000219`dd657b66
0c 0000009f`e2bfe298 00000219`c24226b8     0x00000219`c1080370
0d 0000009f`e2bfe2a0 00000000`00000000     0x00000219`c24226b8

and here is AttachListener:


  12  Id: 5acc.3dac Suspend: 13 Teb: 0000009f`e14f9000 Unfrozen "Attach Listener"
 # Child-SP          RetAddr               Call Site
00 0000009f`e25ffa38 00007fff`3ab8ba09     ntdll!NtFlushBuffersFile+0x14
01 0000009f`e25ffa40 00007fff`11fd5e19     KERNELBASE!FlushFileBuffers+0x29
02 (Inline Function) --------`--------     jvm!PipeChannel::close(void)+0x1f
03 (Inline Function) --------`--------     jvm!PipeChannel::{dtor}(void)+0x2b
04 0000009f`e25ffa80 00007fff`11fd5748     jvm!Win32AttachOperation::`scalar deleting destructor'(void)+0x39
05 0000009f`e25ffab0 00007fff`12569be2     jvm!AttachListenerThread::thread_entry(

Suggested fix:

  void close() {
    if (opened()) {
+   ThreadBlockInVM tbivm;
      FlushFileBuffers(_hPipe);
      CloseHandle(_hPipe);
      _hPipe = INVALID_HANDLE_VALUE;
    }
Comments
Changeset: 53c5b93c Branch: master Author: Alex Menkov <amenkov@openjdk.org> Date: 2025-03-18 17:54:38 +0000 URL: https://git.openjdk.org/jdk/commit/53c5b93ca528ec21628c2b03dd6064e02f7ac408
18-03-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24091 Date: 2025-03-18 00:16:40 +0000
18-03-2025