NationalSecurityAgency/ghidra · error · ElasticException

IOException message

Error message

IOException message

What it means

While decoding a stored feature vector for a queried function, vectorFactory.restoreVectorFromBase64 throws IOException; it is wrapped as ElasticException(e.getMessage()). The vector document's _source.features blob is present but not valid base64 or does not decode to the expected vector length.

Source

Thrown at Ghidra/Features/BSim/src/main/java/ghidra/features/bsim/query/elastic/ElasticDatabase.java:715

			}
			vecRes = iter2.next();
			JsonObject oneResp = (JsonObject) docs.get(i);
			String matchId = oneResp.get("_id").getAsString();
			long matchIdVal = Base64Lite.decodeLongBase64(matchId);
			if (matchIdVal != vecRes.vectorid) {
				throw new ElasticException("Mismatch in vectorid");
			}
			JsonElement source = oneResp.get("_source");
			if (ElasticConnection.isNull(source)) {
				throw new ElasticException("vector document does not exist for id=" + matchId);
			}
			StringReader reader =
				new StringReader(((JsonObject) source).get("features").getAsString());
			try {
				vecRes.vec = vectorFactory.restoreVectorFromBase64(reader, vectorDecodeBuffer);
			}
			catch (IOException e) {
				throw new ElasticException(e.getMessage());
			}
		}
	}

	/**
	 * Given a list of FunctionDescriptions, fill in the matching SignatureRecords
	 * @param listFunctions is the list of functions
	 * @param manager is the FunctionDescription container
	 * @throws ElasticException for communication problems with the server
	 */
	private void queryAssociatedSignatures(List<FunctionDescription> listFunctions,
			DescriptionManager manager) throws ElasticException {
		TreeMap<Long, VectorResult> vecMap = new TreeMap<>();
		for (FunctionDescription fdesc : listFunctions) {				// Collect (unique) vectorids across FunctionDescriptions
			if (fdesc.getSignatureRecord() != null) {
				continue;
			}
			Long key = Long.valueOf(fdesc.getVectorId());

View on GitHub (pinned to d5f144c24d)

Solutions

  1. Re-ingest the affected executable(s) after dropping them so the vector is rewritten.
  2. Verify the database 'settings' string and weight template match the client's configured vector factory.
  3. If corruption is widespread, recreate the BSim database from source executables.
Defensive patterns

Strategy: validation

Validate before calling

// Confirm the client's vector factory settings match the database's stored settings before querying.
if (!clientSettings.equals(db.getSettings())) {
    throw new IllegalStateException("Vector factory settings differ from database; decoding will fail");
}

Type guard

// Predicate: can this client decode this database's vectors?
boolean compatible = clientFactory.getSettings().equals(storedDbSettings);

Try / catch

// Wrap vector decode failures; mark the executable for re-ingest.
try {
    db.querySimilar(req);
} catch (ElasticException e) {
    if (looksLikeDecodeFailure(e)) scheduleReingest(offendingExe);
    else throw e;
}

Prevention

When it happens

Trigger: The query/associated-signature path fetches a vector document whose 'features' field fails to decode via the configured Base64VectorFactory (truncated base64, wrong byte length, or charset corruption).

Common situations: Index corruption; a partial write of a vector document from a crashed/interrupted ingest; version skew between the vector factory (weights/settings template) used to write vs to read; manual edits to the index.

Related errors


AI-assisted analysis of NationalSecurityAgency/ghidra@d5f144c24d (2026-08-14). Data as JSON: /api/errors/0b5517b684660b5a. Report an issue: GitHub.