Critical: WAL Table Corruption Chain: CairoException: [9] Checking file size failed Escalates to Fatal java.lang.InternalError

To reproduce

1. Summary and Severity

My QuestDB instance encountered a severe, repeating error chain on a high-ingestion WAL table (um_klines_1m~10). This chain begins with an ungracefully handled I/O error (CairoException) and escalates to a fatal JVM InternalError during WAL transaction cleanup, compromising the entire service stability.

The service was stabilized only after restart.

2. Observed Error Chain (The Core Problem)

The issue follows a clear pattern:

Step 1: I/O Error during WAL Purge

The WalPurgeJob fails while attempting to access the table's transaction file.

Log Snippet Example (Multiple occurrences, e.g., 2025-11-07T23:59:19Z):

2025-11-07T23:59:19.182966Z E i.q.c.w.WalPurgeJob broad sweep failed [table=um_klines_1m~10, msg=
io.questdb.cairo.CairoException: [9] Checking file size failed
at io.questdb.cairo.CairoException.instance(CairoException.java:370)
at io.questdb.cairo.CairoException.critical(CairoException.java:73)
at io.questdb.std.FilesFacadeImpl.length(FilesFacadeImpl.java:297)
...
, errno=9]

Step 2: Escalation to Fatal JVM Error

Shortly after the CairoException, the core thread responsible for the background work encounters a fatal JVM error while attempting to read the transaction metadata.

Log Snippet Example (Multiple occurrences, e.g., 2025-11-08T02:15:49Z):

2025-11-08T02:15:49.642466Z C server-main unhandled error [job=io.questdb.cairo.wal.WalPurgeJob@424fd310, ex=
java.lang.InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code
at io.questdb.cairo.TxReader.getLong(TxReader.java:663)
at io.questdb.cairo.TxReader.ofRO(TxReader.java:481)
...
]

questdb-rolling.log.20251107.txt
questdb-rolling.log.20251108.txt

QuestDB version:

9.0.2

OS, in case of Docker specify Docker and the Host OS:

Ubuntu 24.04.3 LTS

File System, in case of Docker specify Host File System:

ext4

Full Name:

Chen

Affiliation:

N/A

Have you followed Linux, MacOs kernel configuration steps to increase Maximum open files and Maximum virtual memory areas limit?

• Yes, I have

Additional context

No response

Start with the attached rolling logs and trace the failure through WalPurgeJob, FilesFacadeImpl.length, and TxReader.ofRO/getLong. Reproduce the WAL purge failure on QuestDB 9.0.2 if possible, then determine why the CairoException is followed by the JVM InternalError. Done means the corruption chain is prevented or handled without compromising service stability, with regression coverage for the failure path.