bumptech/glide · error · IllegalStateException

Failed to find entries to evict.

Error message

Failed to find entries to evict.

What it means

Thrown by EvictionManager.evictOnWorkThread() when eviction was deemed necessary (it passed the early-return) but no entries were found to delete: both stale entries and least-recently-used keys came back empty, leaving triedToDeleteEntries == 0. The cache believes it is over capacity yet the journal offers nothing to remove.

Source

Thrown at integration/sqljournaldiskcache/src/main/java/com/bumptech/glide/integration/sqljournaldiskcache/EvictionManager.java:133

      Log.d(TAG, "Starting eviction on work thread");
    }

    int successfullyDeletedCount = 0;
    int triedToDeleteEntries = staleEntriesKeys.size();
    if (!staleEntriesKeys.isEmpty()) {
      successfullyDeletedCount += diskCache.delete(staleEntriesKeys).size();
    }

    long targetSize = maximumSizeBytes - evictionSlopBytes;
    if (isEvictionRequired(maximumSizeBytes)) {
      long bytesToEvict = journal.getCurrentSizeBytes() - targetSize;
      List<String> leastRecentlyUsedKeys = journal.getLeastRecentlyUsed(bytesToEvict);
      triedToDeleteEntries += leastRecentlyUsedKeys.size();
      successfullyDeletedCount += diskCache.delete(leastRecentlyUsedKeys).size();
    }

    if (triedToDeleteEntries == 0) {
      throw new IllegalStateException("Failed to find entries to evict.");
    }

    if (LOG_DEBUG) {
      Log.d(
          TAG,
          "Ran eviction"
              + ", tried to delete: "
              + triedToDeleteEntries
              + " entries"
              + ", actually deleted: "
              + successfullyDeletedCount
              + " entries"
              + ", target journal : "
              + targetSize
              + ", journal size: "
              + journal.getCurrentSizeBytes()
              + ", file size: "
              + fileSystem.getDirectorySize(cacheDirectory));

View on GitHub (pinned to eb14a895d8)

Solutions

1. Clear the disk cache to reset the journal to a consistent state and let it rebuild.
2. Check for a prior crash or partial write that left the journal and files out of sync (see recovery manager logs).
3. Verify the cache directory is not being modified by another process or cleaned externally while Glide runs.
4. Upgrade the sqljournaldiskcache integration, as size-tracking fixes may address the desync.
5. If reproducible, capture the journal size vs actual directory size from logs to file a bug.

Example fix

// before: cache left in inconsistent state, eviction throws

// after: clear and reinitialize the cache
diskCache.clear() // or: delete the cache directory and let Glide recreate it

// Before relying on the cache, verify eviction can proceed by checking journal health
// is non-trivial; the practical guard is to clear the cache on failure.

try {
  diskCache.put(key, data)
} catch (e: IllegalStateException) {
  if (e.message?.contains("Failed to find entries to evict") == true) {
    diskCache.clear() // reset journal and retry once
    diskCache.put(key, data)
  } else throw e
}

When it happens

Trigger: isEvictionRequired(maximumSizeBytes) is true so the method proceeds, but journal.getStaleEntries() returns empty and journal.getLeastRecentlyUsed(bytesToEvict) also returns empty, so nothing was attempted for deletion.

Common situations: Journal/file size desynchronization: the recorded current size exceeds the limit but the underlying entries were already removed (partial delete earlier), or a pending-delete state hides entries from the LRU query. Indicates the journal bookkeeping drifted from real on-disk content.

Related errors

• Size mismatch, expected to be able to evict at least {} byte
• 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/feb0a358e885f0ec. Report an issue: GitHub.