IOUtils.closeWhileSuppressingExceptions stops closing when a close() rethrows the exception being handled

After a failure, Lucene code calls IOUtils.closeWhileSuppressingExceptions(t, closeables...) to close what it had opened and then rethrows t (for example StandardDirectoryReader.java:102-104, and on main the IndexWriter constructor, IndexWriter.java:1206). The helper attaches each close failure e to t with t.addSuppressed(e) (IOUtils.java:129) and never checks that e is a different object. Throwable.addSuppressed rejects its own receiver with IllegalArgumentException("Self-suppression not permitted"), the argument as cause. So when a close() throws the very object being handled, that exception leaves the loop: the closeables after it are never closed, and the caller gets the IllegalArgumentException instead of t. This breaks the method's javadoc, "Even if a Error is thrown all given closeable are closed" (:109-110). The same object is thrown twice when the JVM is out of heap and reuses one OutOfMemoryError, or when an application component rethrows one stored exception. It is in every release with the helper, 10.4.0 to 10.6.0, and main; an identity check before addSuppressed fixes it.

• IOUtils.closeWhileSuppressingExceptions(ex, closeables...): a cleanup helper (IOUtils is @lucene.internal, IOUtils.java:48) used on failure paths as catch (Throwable t) { IOUtils.closeWhileSuppressingExceptions(t, ...); throw t; }. It closes everything and records each close failure on ex; when ex is an Error, it rethrows that Error itself.
• Suppressed exceptions: ex.addSuppressed(e) attaches e to ex. The JDK throws IllegalArgumentException("Self-suppression not permitted", e) when e == ex (JDK 25 Throwable.java:1100-1101).

// IOUtils.java:114-137 (condensed)
Error firstError = ex instanceof Error err ? err : null;   // :116  an Error ex is the one to throw
for (Closeable object : objects) {
  try {
    if (object != null) object.close();                   // :121
  } catch (Throwable e) {
    if (firstError == null && e instanceof Error err) {
      firstError = err;
      firstError.addSuppressed(ex);                        // :127
    } else {
      ex.addSuppressed(e);                                 // :129  e == ex: IllegalArgumentException,
    }                                                      //       thrown out of the loop
  }
}
if (firstError != null) throw firstError;                 // :134-135  never reached

The repro, step by step:

A non-Error ex (an IOException that close() rethrows) takes the same :129 branch and fails the same way; the method should return normally there. Distinct exception objects behave as documented. The :127 call cannot self-suppress: it runs only when ex is not an Error and e is.

• Reach by version. 10.4.0: one in-tree caller, StandardDirectoryReader.open (behind DirectoryReader.open of a directory or commit). 10.5.0 to 10.5.2: five caller files. 10.6.0: six non-sandbox caller files (StandardDirectoryReader, Lucene90DocValuesProducer, Lucene99HnswVectorsWriter, Lucene104ScalarQuantizedVectorsReader and Writer, backward-codecs Lucene102BinaryQuantizedVectorsReader). Main: 72 non-sandbox source files with 100 call sites, including the IndexWriter constructor.
• Trigger. One exception object thrown both by the failed operation and by a later close(). (a) The JVM's shared OutOfMemoryError: in a JDK 25 probe at -Xmx64m the first 4 heap OutOfMemoryErrors were distinct and every later one was the same object, with no stack trace. (b) An application Directory, IndexOutput, IndexDeletionPolicy or MergeScheduler that rethrows one stored exception: on main, IndexWriter.addDocument + commit() on a FilterDirectory whose postings output throws one IOException object twice surfaced the IllegalArgumentException from Lucene104PostingsWriter.<init>, where 10.6.0 surfaced the IOException.
• Effect. Loud: an IllegalArgumentException whose cause is the original. Silent: the closeables after the one that threw stay open, such as the remaining segment readers of a failed DirectoryReader.open (file handles), or on main the IndexWriter write lock, so a second IndexWriter on the directory gets LockObtainFailedException: lock instance already obtained in the same process.
• Caveat (by reasoning, not run). Under real heap exhaustion, allocating the IllegalArgumentException might itself fail, so the shared OutOfMemoryError would escape instead; the remaining closeables are skipped either way. Lucene CI mails have printed this IllegalArgumentException from other sites under heap exhaustion (2020, 2025).
• Scale and likelihood. No scale: one call, single thread, assertions on or off. Rare: no public report of it was found since the helper shipped in 10.4.0.

The test draws no random values; it gave the same result with every seed and assertion mode run. It belongs in lucene/core/src/test/org/apache/lucene/util/ and passes :lucene:core:check -x test (google-java-format, ecj lint, forbidden APIs). It is the minimal test of the hunt with its one comment split into two lines.

The routes through new IndexWriter and IndexWriter.commit (application components that throw one exception object twice) are supporting evidence, not part of the repro.

Regression test: this same test.

TestCloseWhileSuppressingSameThrowable > testCloseRethrowingHandledError FAILED
    java.lang.AssertionError: second closeable not closed
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:AB6C3CE6ACC13F74]:0)
        at org.junit.Assert.fail(Assert.java:89)
        at org.junit.Assert.assertTrue(Assert.java:42)
        at org.apache.lucene.util.TestCloseWhileSuppressingSameThrowable.testCloseRethrowingHandledError(TestCloseWhileSuppressingSameThrowable.java:38)

# what was thrown (an earlier one-test variant with assertSame first, main, assertions on and off):
java.lang.AssertionError: expected same:<java.lang.OutOfMemoryError: shared instance> was not:<java.lang.IllegalArgumentException: Self-suppression not permitted>

• The contract. IOUtils.java:109-110 (the varargs overload, which delegates here, carries only the first sentence, :98). The code deliberately rethrows an Error ex (:116, :135); TestIOUtils.testCloseExposesErrors (TestIOUtils.java:76-110) asserts it is the same instance, but only with close failures that are distinct objects.
• The replaced code handled the repro's case. Before the conversions (main #14633, 2025-05; StandardDirectoryReader.open in #14913, 2025-07-14; on the 10.x line #15445), these paths used a success flag and closeWhileHandlingException, which collects close failures with useOrSuppress and rethrows the first Error (10.3.2 IOUtils.java:113-135, :449-456). When one close() rethrows the handled object, that code closes everything and rethrows it; the new helper fails on that first rethrow. If two closes throw the same object, the old code also fails, in useOrSuppress (LFV-564's site; run against the 10.3.2 core jar).
• Stated intent. CHANGES, LUCENE-5654: "Fix various close() methods that could suppress throwables such as OutOfMemoryError, instead returning scary messages that look like index corruption."
• JDK precedent. FilterOutputStream.close: if (flushException != closeException) closeException.addSuppressed(flushException); (JDK 25 java/io/FilterOutputStream.java:195-196).
• History. The review of #14633 (17 comments and reviews) never discusses a close() that rethrows ex; no javadoc, test, CHANGES or MIGRATE entry forbids it.

The strongest case: plain try-with-resources (JLS 14.20.3.1) also calls primary.addSuppressed(closeFailure) without an identity check, so Java itself throws "Self-suppression not permitted" in this situation; IOUtils is @lucene.internal; the trigger is narrow; and the JDK's AutoCloseable.close javadoc advises "if it would cause problems for an exception to be suppressed, the AutoCloseable.close method should not throw it" (JDK 25 java/lang/AutoCloseable.java:82-84).

Why it fails: try-with-resources still closes every resource after that failure, while this helper skips the rest, which its own javadoc rules out. The skipped closes cannot. The AutoCloseable advice is aimed at application components; it cannot apply to the JVM's shared OutOfMemoryError. Being internal does not remove the reach, because the helper sits on default failure paths of public APIs. The executed cross-model review (OpenAI GPT-5.6) rated the intended-behaviour argument weak; a later cross-model fact check rated it moderate (a maintainer could reasonably close the report as won't-fix), though not enough to make it intended. What survives is a severity argument, hence priority Low.

Validated with gradle in a clean scratch worktree of 5adff78bb168 (OpenJDK 25.0.3, seed DEADBEEF, 2026-11-03): the repro fails stock with assertions on and off and passes with the fix, on and off.

Related fix sites in the same file, not part of this finding: IOUtils.useOrSuppress (:561, LFV-564) and both deleteFilesSuppressingExceptions overloads (:258-260, :352, main only; same pattern by reading). One upstream change could guard them all.

Workaround until fixed: application components should not rethrow one stored exception object from both the failing call and close(); throw a new exception that wraps or suppresses the stored one. Nothing helps for the shared OutOfMemoryError.

In the catch, do nothing when e == ex (for the usual catch/cleanup/rethrow callers no record is needed: the object is already the one the caller will throw) or e == firstError (two closes threw the same Error while ex is not one; stock code then attaches it to ex, which that Error already carries as suppressed, a redundant cyclic record visible through getSuppressed() that the guard deliberately drops; by reading). Everything else is unchanged.

--- a/lucene/core/src/java/org/apache/lucene/util/IOUtils.java
+++ b/lucene/core/src/java/org/apache/lucene/util/IOUtils.java
@@ -121,7 +121,9 @@
           object.close();
         }
       } catch (Throwable e) {
-        if (firstError == null && e instanceof Error err) {
+        if (e == ex || e == firstError) {
+          // the same Throwable was rethrown by close(): nothing to suppress
+        } else if (firstError == null && e instanceof Error err) {
           // don't try and suppress it - this Error should be the thing that is thrown
           firstError = err;
           firstError.addSuppressed(ex);

Trade-offs

Smallest change; fixes both halves (every closeable is closed, the caller's own exception survives). It covers only this method; the sibling sites need the same check.

What the checks validated

Gradle, scratch worktree of 5adff78bb168: the repro passes with assertions on and off (stock fails, on and off); the repro, TestIOUtils (12), TestDirectoryReader (34) and TestIndexWriterExceptions (40, 3 skipped): 87 tests, 0 failures; :lucene:core:check -x test passes. Standalone runs of the same diff passed the minimal test with assertions on and off.

A private suppress(Throwable into, Throwable t) that skips t == into, used here, in both deleteFilesSuppressingExceptions overloads and in useOrSuppress (LFV-564's site).

Trade-offs

One consistent rule for LFV-564 and this bug, but a larger diff that touches methods outside this finding; the cycle case (e == firstError) still needs its own check here. Not run.

Catch the exception that addSuppressed throws, hold it, and rethrow it only after every closeable has been closed. A bare try/finally would not do: the exception would still leave the loop.

Trade-offs

Every closeable is closed, but the caller still gets the IllegalArgumentException instead of its own exception; the identity check fixes both halves with less code. Not run.

Method: semi-formal (a proof-obligation audit of a class's contract, witnessed by an executable repro), on main 5adff78bb168, 2026-11-03.

• The obligation: for every closeable, close() is called, whatever earlier closes threw (:109-110). It fails when the catch block itself can throw: ex.addSuppressed(e) (:129) throws for e == ex, a case the JDK specifies.
• A one-test JUnit witnessed it on main with assertions on and off; a JVM probe showed the shared OutOfMemoryError is real JVM behaviour. An independent reproducer, an executed review by another model family (OpenAI GPT-5.6) and a devil's-advocate verifier wrote their own tests from the claim, including two routes through IndexWriter.