NationalSecurityAgency/ghidra · error · UnsupportedOperationException

Region is from a forked snapshot

Error message

Region is from a forked snapshot

What it means

Thrown as UnsupportedOperationException by checkSnapOnSet (used by setPermissions and other mutators) when the program view's current snap differs from the snap at which the region block was created. Region state is snap-specific in traces, so mutating a region block built for snap X while the view sits at snap Y is disallowed to prevent corrupting a different snapshot's view.

Source

Thrown at Ghidra/Debug/Framework-TraceModeling/src/main/java/ghidra/trace/database/program/DBTraceProgramViewMemoryRegionBlock.java:63

	@Override
	protected AddressSpace getAddressSpace() {
		return region.getRange(snap).getAddressSpace();
	}

	@Override
	public AddressRange getAddressRange() {
		return region.getRange(snap);
	}

	protected void checkSnapOnSet() {
		long snap = program.getSnap();
		if (snap != this.snap) {
			/**
			 * TODO: Copy the region to here? It would immediately invalidate this block, but I
			 * suppose that's okay, as long as the UI updates appropriately.
			 */
			throw new UnsupportedOperationException("Region is from a forked snapshot");
		}
	}

	@Override
	public void setPermissions(boolean read, boolean write, boolean execute) {
		checkSnapOnSet();
		region.setRead(snap, read);
		region.setWrite(snap, write);
		region.setExecute(snap, execute);
	}

	@Override
	public int getFlags() {
		int bits = 0;
		for (TraceMemoryFlag flag : region.getFlags(snap)) {
			bits |= flag.getBits();
		}
		return bits;

View on GitHub (pinned to d5f144c24d)

Solutions

1. Re-acquire the region block at the current snap before mutating: ensure program.getSnap() == block.snap.
2. Set the view's snap back to the block's snap before calling mutators.
3. Capture the snap with the block and only mutate within the same snap context; avoid caching block handles across snap changes.

Example fix

// before
block.setPermissions(true, false, true); // throws if view moved snaps

// after
if (program.getSnap() == blockSnap) {
    block.setPermissions(true, false, true);
} else {
    // re-fetch block at current snap, or set view snap
}

// Only mutate the region block at the snap it was created
if (program.getSnap() == blockSnap) {
    block.setPermissions(r, w, x);
} else {
    // re-fetch block at current snap or set the view snap
}

When it happens

Trigger: Creating a DBTraceProgramViewMemoryRegionBlock at snap A, then calling setPermissions/set on it after the program view has moved to snap B (snap != this.snap).

Common situations: Navigating the view to a different snap after binding a region block handle. Forking snapshots and then operating on a block handle captured before the fork. Long-lived block references used across snap switches.

Related errors

• All trace memory is initialized
• Mapped blocks are not supported in traces
• Traces do not support externals
• Cannot use program view to set the trace name
• Given bookmark is not present at this view's snap

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