bumptech/glide · error · IllegalStateException
Size mismatch, expected to be able to evict at least {} byte
Error message
Size mismatch, expected to be able to evict at least {} bytes, but only found {} bytes worth of entries! What it means
Thrown by Journal.getLeastRecentlyUsed() when it has exhausted all LRU-batched entries (isOutOfEntries) but the cumulative bytes of found entries (currentByteCount) is still below the targetByteCount the caller asked to evict. The journal's recorded size claims more bytes exist than the rows actually account for.
Source
Thrown at integration/sqljournaldiskcache/src/main/java/com/bumptech/glide/integration/sqljournaldiskcache/Journal.java:235
String key = cursor.getString(keyIdx);
keys.add(key);
long sizeBytes = cursor.getLong(sizeIdx);
currentByteCount += sizeBytes;
}
isOutOfEntries = cursor.getCount() < LRU_BATCH_SIZE;
} finally {
cursor.close();
}
currentOffset += LRU_BATCH_SIZE;
}
// TODO(judds): for a sufficiently large file or small cache size and a failed attempt to commit
// a put, this can happen because our journal size will temporarily not match our File size.
// If this becomes an issue, we can safely just clear the cache here instead of throwing because
// we were about to delete all the files anyway.
if (isOutOfEntries && currentByteCount < targetByteCount) {
throw new IllegalStateException(
"Size mismatch"
+ ", expected to be able to evict at least "
+ targetByteCount
+ " bytes"
+ ", but only found "
+ currentByteCount
+ " bytes worth of entries!");
}
return keys;
}
List<String> getStaleEntries(long staleTimeThresholdMs) {
SQLiteDatabase db = dbHelper.getReadableDatabase();
List<String> keys = new ArrayList<>();
long currentRowId = 0L;
boolean isOutOfEntries = false;
while (!isOutOfEntries) {View on GitHub (pinned to eb14a895d8)
Solutions
- Clear the disk cache to force a clean journal rebuild (the code comment notes clearing is safe here since eviction was about to delete everything anyway).
- Upgrade the sqljournaldiskcache integration for size-tracking robustness.
- Investigate prior write/commit failures (device ran low on storage, process killed mid-write) that could have desynced sizes.
- Ensure no external process alters files in the cache directory.
Defensive patterns
Strategy: fallback
Try / catch
try {
diskCache.put(key, data)
} catch (e: IllegalStateException) {
if (e.message?.contains("Size mismatch") == true) {
diskCache.clear() // safe per code comment; eviction was about to delete all
} else throw e
} Prevention
- Treat size-mismatch as a signal to reset the journal via clear().
- Investigate prior write/commit failures that desync sizes.
- Prevent concurrent external access to the cache directory.
When it happens
Trigger: The cursor loop reads entries in LRU_BATCH_SIZE chunks; after the last batch isOutOfEntries becomes true, yet currentByteCount < targetByteCount, so the guard at line 235 fires. This is a size-accounting mismatch between journal metadata and the rows queryable for eviction.
Common situations: A failed/partial commit left a journal row whose size was decremented but whose file still contributes, or vice versa; the on-disk file size differs from the summed entry sizes after an interrupted put. The source TODO notes this can happen for large files/small caches after a failed commit.
Related errors
- Failed to find entries to evict.
- Failed to delete entry, key: {}, size: {}, actually deleted:
- Cannot call evictOnWorkThread on thread: {}
- Failed to create cache directory: {}
- Cannot run recovery on a thread other than the work thread!
AI-assisted analysis of bumptech/glide@eb14a895d8 (2026-08-14).
Data as JSON: /api/errors/f29f500ccd1222dd.
Report an issue: GitHub.