NationalSecurityAgency/ghidra · error · UnsupportedOperationException

Mapped blocks are not supported in traces

Error message

Mapped blocks are not supported in traces

What it means

Thrown as UnsupportedOperationException by createBitMappedBlock because trace program views do not support bit-mapped overlay blocks. Mapped blocks (where one block mirrors another address range at the bit level) are a regular-Program feature that has no equivalent in the trace memory model, where memory is laid out per address space and snap.

Source

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

			byte initialValue, TaskMonitor monitor, boolean overlay)
			throws LockException, MemoryConflictException, AddressOverflowException,
			CancelledException {
		// TODO: Create a region?
		throw new UnsupportedOperationException();
	}

	@Override
	public MemoryBlock createUninitializedBlock(String name, Address start, long size,
			boolean overlay)
			throws LockException, MemoryConflictException, AddressOverflowException {
		throw new UnsupportedOperationException("All trace memory is initialized");
	}

	@Override
	public MemoryBlock createBitMappedBlock(String name, Address start, Address mappedAddress,
			long length, boolean overlay) throws LockException, MemoryConflictException,
			AddressOverflowException, IllegalArgumentException {
		throw new UnsupportedOperationException("Mapped blocks are not supported in traces");
	}

	@Override
	public MemoryBlock createByteMappedBlock(String name, Address start, Address mappedAddress,
			long length, ByteMappingScheme byteMappingScheme, boolean overlay)
			throws LockException, MemoryConflictException, AddressOverflowException,
			IllegalArgumentException {
		throw new UnsupportedOperationException("Mapped blocks are not supported in traces");
	}

	@Override
	public MemoryBlock createBlock(MemoryBlock block, String name, Address start, long length)
			throws LockException, MemoryConflictException, AddressOverflowException {
		throw new UnsupportedOperationException();
	}

	@Override
	public void removeBlock(MemoryBlock block, TaskMonitor monitor) throws LockException {

View on GitHub (pinned to d5f144c24d)

Solutions

1. Avoid createBitMappedBlock on traces; it is unsupported by design.
2. Model the mirrored data explicitly by writing the same bytes to both locations in the trace, if needed.
3. Use a real Program rather than a trace view if bit-mapped blocks are essential to your workflow.

Example fix

// before
mem.createBitMappedBlock("mirror", start, mappedAddr, len, false);

// after
// not supported on traces; write data to both ranges explicitly
space.putBytes(snap, start, buf);
space.putBytes(snap, mappedAddr, buf);

// Skip bit-mapped block creation on trace views
if (!(program.getMemory() instanceof DBTraceProgramViewMemory)) {
    mem.createBitMappedBlock(name, start, mappedAddr, length, overlay);
}

static boolean supportsMappedBlocks(Memory m) {
    return !(m instanceof DBTraceProgramViewMemory);
}

When it happens

Trigger: Calling createBitMappedBlock(name, start, mappedAddress, length, overlay) on a DBTraceProgramViewMemory instance.

Common situations: Reusing generic Program memory-layout code that creates bit-mapped blocks on a trace view. Attempting to set up register-bank mirrors or address aliasing via bit mapping on a trace.

Related errors

• All trace memory is initialized
• Space does not exist
• Traces do not support externals
• Cannot use program view to set the trace name
• Region is from a forked snapshot

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