NationalSecurityAgency/ghidra · error · UnsupportedOperationException

All trace memory is initialized

Error message

All trace memory is initialized

What it means

Thrown as UnsupportedOperationException by createUninitializedBlock because Ghidra traces model all memory as conceptually initialized — every byte has a defined value (which may represent 'unknown' state internally) rather than uninitialized holes. The regular-program concept of an uninitialized memory block does not apply to traces.

Source

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

		// TODO: Copy contents in?
		//   NOTE: Would not be backed by the fileBytes, but a copy
		throw new UnsupportedOperationException();
	}

	@Override
	public MemoryBlock createInitializedBlock(String name, Address start, long size,
			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

View on GitHub (pinned to d5f144c24d)

Solutions

  1. Do not call createUninitializedBlock on a trace; trace memory is always initialized. Instead create/use initialized regions through the trace's memory manager.
  2. If you need an 'unknown' region, create an initialized block and leave its state as UNKNOWN via the trace memory-state API.
  3. Use a real Program (not a trace program view) if your workflow genuinely requires uninitialized blocks.

Example fix

// before
mem.createUninitializedBlock("bss", startAddr, size, false);

// after
// trace memory is always initialized; create a region instead
trace.getMemoryManager().createRegion("bss", snap, range);
Defensive patterns

Strategy: validation

Validate before calling

// Trace memory is always initialized; skip createUninitializedBlock on trace views
if (!(program.getMemory() instanceof DBTraceProgramViewMemory)) {
    mem.createUninitializedBlock(name, start, size, overlay);
}

Type guard

// Detect a trace-backed memory implementation
static boolean isTraceMemory(Memory m) {
    return m instanceof DBTraceProgramViewMemory;
}

Prevention

When it happens

Trigger: Calling createUninitializedBlock(name, start, size, overlay) on a DBTraceProgramViewMemory (the trace-backed memory implementation). This API is inherited from the Program Memory interface but is intentionally not implemented for traces.

Common situations: Porting Program-creation code that builds uninitialized blocks directly onto a trace program view. Misusing a trace program view (read/snapshot-oriented) as if it were a full editable Program for laying out memory.

Related errors


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