Close the .xsb stream when XsbReader rejects a header - #107
Merged
Conversation
XsbReader(typeSystem, handle, filetype) opens the resource stream before it
validates the header, then throws SchemaTypeLoaderException for a bad magic
cookie, an incompatible major/minor version or the wrong file type - and
StringPool.readFrom can throw on a truncated file. The constructor never
returns in those cases, so no caller ever holds a reference to call readEnd()
and the stream is leaked.
SchemaTypeSystemImpl.initFromHeader already guards with
"finally { if (reader != null) reader.readEnd(); }", but reader is still null
for exactly this failure. Every corrupt or version-mismatched .xsb on the
classpath therefore leaks a file or zip-entry handle.
Move the header parsing into readHeader() and release the stream from the
constructor if it does not complete.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
XsbReader(SchemaTypeSystemImpl, String handle, int filetype)opens the resource stream (typeSystem.getLoaderStream(...)) and only then validates the header. Every rejection path — wrong magic cookie, wrong major version, incompatible minor version, wrong file type — throwsSchemaTypeLoaderExceptionfrom inside the constructor, andStringPool.readFromcan throw on a truncated file too.Because the constructor never returns, no caller ever holds a reference to call
readEnd(), so the stream is leaked.SchemaTypeSystemImpl.initFromHeader()even hasbut
readeris stillnullin exactly this case. Each corrupt or version-mismatched.xsbon the classpath leaks a file handle (or aZipFileentry stream).The header parsing moves into a private
readHeader()and the constructor releases the stream if it does not complete.Added
XsbReaderHeaderStreamTest, which feeds a tracking stream through a stubResourceLoaderand asserts it is closed. All four cases fail on trunk and pass with this change.🤖 Generated with Claude Code