NationalSecurityAgency/ghidra · critical · TraceRmiError

Cannot receive TraceRmi message with excessive message lengt

Error message

Cannot receive TraceRmi message with excessive message length

What it means

Thrown by TraceRmiHandler.recvDelimited when the 4-byte length prefix read from the socket exceeds MAX_MSG_LENGTH (64 KiB). This is a defensive guard against a malformed or hostile peer sending an implausibly large framing length, which would otherwise trigger a huge allocation (OOM). It signals a protocol desync or an incompatible/buggy peer.

Source

Thrown at Ghidra/Debug/Debugger-rmi-trace/src/main/java/ghidra/app/plugin/core/debug/service/tracermi/TraceRmiHandler.java:452

		int total = 0;
		while (total < len) {
			int l = in.read(buf, total, len - total);
			if (l <= 0) {
				return null;
			}
			total += l;
		}
		return buf;
	}

	protected static RootMessage recvDelimited(InputStream in) throws IOException {
		byte[] lenBuf = recvAll(in, Integer.BYTES);
		if (lenBuf == null) {
			return null;
		}
		int len = ByteBuffer.wrap(lenBuf).getInt();
		if (len > MAX_MSG_LENGTH) {
			throw new TraceRmiError(
				"Cannot receive TraceRmi message with excessive message length");
		}
		byte[] datBuf = recvAll(in, len);
		if (datBuf == null) {
			return null;
		}
		RootMessage msg = RootMessage.parseFrom(datBuf);
		return msg;
	}

	long dbgSeq = 0;

	protected boolean send(RootMessage rep) {
		try {
			synchronized (out) {
				sendDelimited(out, rep, dbgSeq++);
			}
			return true;

View on GitHub (pinned to d5f144c24d)

Solutions

1. Verify client and server run compatible Ghidra versions (TraceRmiHandler.VERSION, currently '12.2').
2. Confirm the socket endpoint is actually a TraceRmi server and not another service.
3. Treat this as fatal for the connection: close the socket and re-establish it, rather than trying to resync a desynced stream.
4. Inspect backend logs for the matching 'excessive length' send-side error to find which side is malformed.

try {
    RootMessage msg = TraceRmiHandler.recvDelimited(in);
} catch (TraceRmiError e) {
    // peer sent an oversized/invalid length; close socket and reconnect
    socket.close();
}

When it happens

Trigger: The remote endpoint writes a length prefix larger than 64 KiB; the byte stream is corrupted so the length field is garbage; the peer runs a different protocol version that uses different framing; a partial/offset read desynchronized the stream.

Common situations: Connecting a Ghidra TraceRmi backend of an incompatible version; connecting to a port that is not a TraceRmi server; socket corruption; a backend that violates the 64 KiB cap when sending.

Related errors

• Cannot send TraceRmi message with excessive length
• Could not receive negotiation request
• Could not respond during negotiation
• Protocol error: Invalid value kinds
• Could not send request

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