JetBrains/intellij-community · error · ExecutionException

ATTACH_VM_FAILED

Error message

ATTACH_VM_FAILED

What it means

ExternalSystemTaskDebugRunner attaches the IntelliJ debugger to a Gradle/Maven test JVM via DebuggerManagerEx.attachVirtualMachine with a RemoteConnection on the configured debug port (127.0.0.1:<debugPort>). attachVirtualMachine returns null when the attach fails (VM did not open the debug port, connection handshake failed, timeout of DebugEnvironment.LOCAL_START_TIMEOUT); the runner then throws ExecutionException with the raw 'ATTACH_VM_FAILED' text.

Source

Thrown at java/execution/impl/src/com/intellij/openapi/externalSystem/service/execution/ExternalSystemTaskDebugRunner.java:128

    descriptor.setRunnerLayoutUi(runContentDescriptor.getRunnerLayoutUi());
    return descriptor;
  }

  private static @NotNull XDebugProcess jvmProcessToDebug(
    @NotNull XDebugSession session,
    ExternalSystemRunnableState state,
    @NotNull ExecutionEnvironment env
  ) throws ExecutionException {
    String debugPort = String.valueOf(state.getDebugPort());
    RemoteConnection connection = state.isDebugServerProcess()
                                  ? new RemoteConnection(true, "127.0.0.1", debugPort, true)
                                  : new RemoteConnectionStub(true, "127.0.0.1", debugPort, true);
    DebugEnvironment environment = new DefaultDebugEnvironment(env, state, connection, DebugEnvironment.LOCAL_START_TIMEOUT);

    final DebuggerSession debuggerSession = DebuggerManagerEx.getInstanceEx(env.getProject()).attachVirtualMachine(environment);

    if (debuggerSession == null) {
      throw new ExecutionException(ATTACH_VM_FAILED);
    }

    final DebugProcessImpl debugProcess = debuggerSession.getProcess();


    XDebugSessionImpl sessionImpl = (XDebugSessionImpl)session;
    ExecutionResult executionResult = debugProcess.getExecutionResult();
    sessionImpl.addExtraActions(executionResult.getActions());
    if (executionResult instanceof DefaultExecutionResult) {
      sessionImpl.addRestartActions(((DefaultExecutionResult)executionResult).getRestartActions());
    }
    return JavaDebugProcess.create(session, debuggerSession);
  }

  private static @Nullable RunContentDescriptor createProcessToDebug(
    ExternalSystemRunnableState state,
    @NotNull ExecutionEnvironment env
  ) throws ExecutionException {

View on GitHub (pinned to be881553f2)

Solutions

  1. Stop all Gradle daemons (./gradlew --stop) and retry — stale daemons do not accept the new JDWP settings
  2. Disable parallel/forked test execution temporarily (org.gradle.parallel=false, maxParallelForks=1) so exactly one JVM opens the port
  3. Check firewall/antivirus allows loopback connections; on WSL2 ensure networking mode supports localhost forwarding
  4. If builds are slow, increase attach timeout via Registry/debugger settings and try again
  5. As a fallback, run the tests with the IDE's native JUnit runner (delegate build/run to IntelliJ in Gradle settings) instead of debugging through Gradle

Example fix

# before: gradle.properties has org.gradle.parallel=true + forkEvery tests
# after:
org.gradle.parallel=false
# and in build.gradle: test { maxParallelForks = 1 }
Defensive patterns

Strategy: retry

Validate before calling

// before attach: confirm the debug port is actually listening
try (Socket s = new Socket()) {
  s.connect(new InetSocketAddress("127.0.0.1", debugPort), 2000);
} catch (IOException io) {
  return error("Target JVM did not open debug port " + debugPort);
}

Try / catch

DebuggerSession session = null;
for (int attempt = 0; attempt < 2 && session == null; attempt++) {
  session = DebuggerManagerEx.getInstanceEx(project).attachVirtualMachine(env);
}
if (session == null) throw new ExecutionException("ATTACH_VM_FAILED");

Prevention

When it happens

Trigger: Debugging an External System (Gradle/Maven) task: the child JVM either never started with the expected -agentlib:jdwp arguments, the debug port was taken/firewalled, the build finished before attach, or the handshake exceeded LOCAL_START_TIMEOUT.

Common situations: Gradle daemon reuse conflicts with debug ports; test JVM forked by Gradle with different JDWP args; firewall/antivirus blocking 127.0.0.1 loopback sockets; heavy builds exceeding attach timeout; running with a Gradle version that filters agent args; WSL2 loopback networking quirks.

Related errors


AI-assisted analysis of JetBrains/intellij-community@be881553f2 (2026-08-14). Data as JSON: /api/errors/8c20e92427404496. Report an issue: GitHub.