lutzroeder/netron · error · Error

Unexpected end of file. Expected ${this._offset - this._leng

Error message

Unexpected end of file. Expected ${this._offset - this._length} more bytes. The file might be corrupted.

What it means

During random access into the HDF5 file image, the reader seeks to a byte offset that is past the end of the data it holds (this._offset > this._length) and aborts. Every seek past EOF is treated as evidence of structural corruption, because in a well-formed HDF5 file all offsets stored in headers point inside the file.

Source

Thrown at source/hdf5.js:516

        this._offsetSize = offsetSize;
        this._lengthSize = lengthSize;
    }

    get position() {
        return this._position + this._offset;
    }

    take(offset) {
        const position = this._offset + this._position;
        this.skip(offset);
        return position;
    }

    seek(position) {
        this._offset = position;
        this._position = 0;
        if (this._offset > this._length) {
            throw new Error(`Unexpected end of file. Expected ${this._offset - this._length} more bytes. The file might be corrupted.`);
        }
    }

    skip(offset) {
        this._position += offset;
        if (this._offset + this._position > this._buffer.length) {
            throw new hdf5.Error(`Unexpected end of file. Expected ${this._offset + this._position - this._buffer.length} more bytes. The file might be corrupted.`);
        }
    }

    align(mod) {
        if (this._position % mod !== 0) {
            this._position = (Math.floor(this._position / mod) + 1) * mod;
        }
    }

    peek(length) {
        const position = this._offset + this._position;

View on GitHub (pinned to d8a543f5f8)

Solutions

Confirm the file is a valid HDF5 file (check the \x89HDF\r\n\x1a\n signature at byte 0) before opening it.
Re-download or re-export the file and compare checksums; truncation is the most common cause.
Reproduce with the official h5dump/h5ls tools — if they also fail, the file itself is damaged.
If the file is valid, report a parser bug with the file to the library maintainers.

Example fix

null

Defensive patterns

Strategy: validation

Validate before calling

function canSeek(reader, position) {
  return Number.isInteger(position) && position >= 0 && position <= reader._length;
}
if (canSeek(reader, targetOffset)) reader.seek(targetOffset); else handleCorruptFile();

Type guard

function isValidHdf5Offset(pos, fileLength) {
  return typeof pos === 'number' && pos >= 0 && pos < fileLength;
}

Try / catch

try {
  reader.seek(addr);
} catch (e) {
  if (/Unexpected end of file/.test(e.message)) {
    reportCorruptOrTruncatedFile(file);
  } else throw e;
}

Prevention

Verify the \x89HDF\r\n\x1a\n signature before opening.
Transfer HDF5 files with checksum verification to avoid truncation.
Wrap the whole open/parse flow in a single try/catch that surfaces 'file may be corrupted' UX.

When it happens

Trigger: Calling seek(position) with an offset beyond the buffer/stream length — typically indirectly, when a parsed object header, B-tree, or local heap yields an address larger than the file size. This variant guards the buffered reader (compare with the stream-based seek at line ~584) and fires after this._offset is assigned.

Common situations: Truncated downloads of .h5/.hdf5 files, files corrupted in transfer, reading a non-HDF5 file through the HDF5 front-end (magic mismatch misleads the parser into garbage offsets), or a user-generated file with wrong superblock version assumptions.

Related errors

AI-assisted analysis of lutzroeder/netron@d8a543f5f8 (2026-08-27). Data as JSON: /api/errors/ad48f7fbfba5a331. Report an issue: GitHub.