oracle/graal · warning · IOException

Error deleting %s. This is most likely due to a compilation

Error message

Error deleting %s. This is most likely due to a compilation on another thread holding an open handle to a file within this directory. Please delete the directory manually once the VM exits.

What it means

After a diagnostic dump directory is archived, StandardPathUtilitiesProvider deletes the original files; each delete failure is collected and, if any remain, this IOException is thrown with the last error chained. It explains the typical cause: another compilation thread still holds an open handle to a file inside the directory, so deletion is deferred to the user after VM exit.

Source

Thrown at compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/debug/StandardPathUtilitiesProvider.java:221

                });
                // Keep this in sync with the catch_files in ci/common.jsonnet
                TTY.println(DIAGNOSTIC_OUTPUT_DIRECTORY_MESSAGE_FORMAT, zipFile);
                return zipFile.getAbsolutePath();
            } catch (IOException e) {
                toDelete.clear();
                throw new IOException("Error archiving " + dir + ". This directory will not be deleted and must be manually removed.", e);
            } finally {
                if (!toDelete.isEmpty()) {
                    IOException lastDeletionError = null;
                    for (Path p : toDelete) {
                        try {
                            Files.delete(p);
                        } catch (IOException e) {
                            lastDeletionError = e;
                        }
                    }
                    if (lastDeletionError != null) {
                        throw new IOException("Error deleting " + dir + ". This is most likely due to a compilation on " +
                                        "another thread holding an open handle to a file within this directory. " +
                                        "Please delete the directory manually once the VM exits.", lastDeletionError);
                    }
                }
            }
        }
        return null;
    }
}

View on GitHub (pinned to a66e9ccd1d)

Solutions

As the message says: delete the directory manually once the VM exits — the archive zip referenced in the preceding log line already contains the data.
Give each compilation/run its own -Dgraal.DumpPath subdirectory so cleanups never overlap.
Exclude dump directories from antivirus/on-access scanners, or move DumpPath off network/locked filesystems.
Periodically purge old dump roots from CI machines to keep stray directories from accumulating.

Defensive patterns

Strategy: try-catch

Try / catch

try {
    provider.cleanupAndArchiveOutputs(dir);
} catch (IOException e) {
    if (e.getMessage().startsWith("Error deleting")) {
        // archive already succeeded; directory removal is cosmetic — handle after VM exit
        LOG.info("{}", e.getMessage());
    } else {
        throw e;
    }
}

Prevention

On Windows, exclude dump directories from antivirus scanning and expect deferred deletion when compilations overlap.
Add an end-of-run sweep that deletes leftover dump directories after the JVM exits.

When it happens

Trigger: Two compilations dumping into the same output directory concurrently — one thread's channel/writer is still open when the other thread's cleanup walks and deletes the tree. On Unix an open handle does not usually block unlink, so this is most characteristic of Windows semantics or NFS/overlay filesystems; files locked by external tools (AV scanners, editors) produce it too.

Common situations: Windows development machines running multi-threaded Graal compilations with dumping enabled; antivirus/indexers briefly locking freshly written dump files; network filesystems with mandatory locking. Benign in the sense that the archive succeeded — only cleanup failed.

Related errors

AI-assisted analysis of oracle/graal@a66e9ccd1d (2026-08-14). Data as JSON: /api/errors/4efa7165edeab54f. Report an issue: GitHub.