skylot/jadx · error · RuntimeException

Fallback parser can't find entry: {}

Error message

Fallback parser can't find entry: {}

What it means

Thrown by useFallbackParser() when, after the custom parser failed on an entry and jadx transparently delegated to the fallback parser, the fallback parser's searchEntry() returns null for the same entry name. This indicates an internal inconsistency: the primary parser knew about the entry but the fallback (which enumerates via Java's ZipFile) cannot locate it. The entry name is included in the message.

Source

Thrown at jadx-commons/jadx-zip/src/main/java/jadx/zip/parser/JadxZipParser.java:368

		}
	}

	private void entryParseFailed(JadxZipEntry entry, Exception e) {
		if (isEncrypted(entry)) {
			throw new RuntimeException("Entry is encrypted, failed to decompress: " + entry, e);
		}
		if (flags.contains(ZipReaderFlags.DONT_USE_FALLBACK)) {
			throw new RuntimeException("Failed to decompress zip entry: " + entry + ", error: " + e.getMessage(), e);
		}
		LOG.warn("Entry '{}' parse failed, switching to fallback parser", entry, e);
	}

	@SuppressWarnings("resource")
	private IZipEntry useFallbackParser(JadxZipEntry entry) {
		LOG.debug("useFallbackParser used for {}", entry);
		IZipEntry zipEntry = initFallbackParser().searchEntry(entry.getName());
		if (zipEntry == null) {
			throw new RuntimeException("Fallback parser can't find entry: " + entry);
		}
		return zipEntry;
	}

	@SuppressWarnings("resource")
	private synchronized ZipContent initFallbackParser() {
		if (fallbackZipContent == null) {
			try {
				fallbackZipContent = new FallbackZipParser(zipFile, options).open();
			} catch (Exception e) {
				throw new RuntimeException("Fallback parser failed to open file: " + zipFile, e);
			}
		}
		return fallbackZipContent;
	}

	private boolean isEncrypted(JadxZipEntry entry) {
		int flags = readFlags(entry);

View on GitHub (pinned to e738a26571)

Solutions

1. Inspect the entry name for unusual characters, case, or path separators that the two parsers might normalize differently.
2. Repackage the archive with a standard zip tool to restore local/central directory consistency.
3. Enable DONT_USE_FALLBACK if you want the original decompression error surfaced instead of this secondary lookup failure.
4. Treat the archive as untrusted and re-acquire it.

try {
    zipEntry = useFallbackFor(entry);
} catch (RuntimeException e) {
    if (e.getMessage().contains("can't find entry")) {
        LOG.warn("Entry {} missing from fallback parser, skipping", entry.getName());
        continue;
    }
    throw e;
}

When it happens

Trigger: Decompression of an entry fails in the custom parser, DONT_USE_FALLBACK is NOT set, so useFallbackParser runs, and initFallbackParser().searchEntry(entry.getName()) returns null.

Common situations: A tampered zip where the central directory (read by the custom parser) lists an entry that the local-file-header enumeration (used by the fallback) cannot find, or vice versa; case-sensitivity or path-normalization differences between the two parsers; an archive edited after creation that broke local/central directory consistency.

Related errors

• Failed to read bytes for entry: {}
• Failed to open input stream for entry: {}
• Failed to open zip: {}, error: {}
• Failed to decompress zip entry: {}, error: {}
• Fallback parser failed to open file: {}

AI-assisted analysis of skylot/jadx@e738a26571 (2026-08-14). Data as JSON: /api/errors/7ea5da6d371754e7. Report an issue: GitHub.