openjdk/jdk · warning
%s: %d->internal error: pendingMessageStatus=0x%X, pendingDa
Error message
%s: %d->internal error: pendingMessageStatus=0x%X, pendingDataLength=%d
What it means
An internal-invariant failure in the macOS MIDI input byte-stream parser (readBytesReceived / MIDI packet processing in MidiUtils.c). When a running-status or system-common message is fully accumulated, the code expects pendingDataLength to be exactly 1 or 2 data bytes; any other value means the state machine corrupted itself (status was set without a matching expected data length). It flags the byte invalid and skips it rather than crashing.
Source
Thrown at src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:319
}
} else {
if (byte < 0x80) {
// Not a status byte -- check our history.
if (handle->readingSysExData) {
CFDataAppendBytes(handle->readingSysExData, &byte, 1);
} else if (pendingDataIndex < pendingDataLength) {
pendingData[pendingDataIndex] = byte;
pendingDataIndex++;
if (pendingDataIndex == pendingDataLength) {
// This message is now done -- do the final processing.
if (pendingDataLength == 2) {
packedMsg = pendingMessageStatus | pendingData[0] << 8 | pendingData[1] << 16;
} else if (pendingDataLength == 1) {
packedMsg = pendingMessageStatus | pendingData[0] << 8;
} else {
fprintf(stderr, "%s: %d->internal error: pendingMessageStatus=0x%X, pendingDataLength=%d\n",
__FILE__, __LINE__, pendingMessageStatus, pendingDataLength);
byteIsInvalid = TRUE;
}
pendingDataLength = 0;
}
} else {
// Skip this byte -- it is invalid.
byteIsInvalid = TRUE;
}
} else {
if (handle->readingSysExData /* && (byte == 0xF7) */) {
// We have reached the end of system exclusive message -- send it finally.
const UInt8* bytes = CFDataGetBytePtr(handle->readingSysExData);
CFIndex size = CFDataGetLength(handle->readingSysExData);
MIDI_QueueAddLong(handle->h.queue,
(UBYTE*) bytes,
(UINT32) size,
0, // Don't care, windowish porting only.View on GitHub (pinned to 88dfb74bbe)
Solutions
- Reproduce with the same device on another machine/OS to confirm the device or its driver emits the malformed stream
- Update or replace the MIDI interface driver/firmware; test with a known-good device such as a mainstream USB keyboard
- If using a virtual port, validate the bytes you inject: every status byte must be followed by exactly its protocol data length
- Filter the device with MidiDevice.getTransmitter() only for devices you control, or ignore the stderr line — the parser skips the bad byte and recovers
Defensive patterns
Strategy: fallback
Prevention
- If you feed virtual MIDI ports, emit protocol-conformant streams: correct data lengths per status byte
- Test your devices with a MIDI monitor (e.g. MIDI Ox equivalent) before wiring them into Java
- Treat the message as recoverable noise: the parser skips the byte and keeps going
When it happens
Trigger: A CoreMIDI device/driver delivers a malformed running-status sequence: a status byte whose expected data length was computed as 0 or >2 (e.g. an undefined 0xF4/0xF5 status becoming pending), followed by data bytes that complete the 'message'. Also triggered by drivers that fragment packets in ways that leave stale pendingMessageStatus from a prior message.
Common situations: Misbehaving or non-standard MIDI hardware (cheap USB-MIDI cables, class-compliant devices with buggy firmware); virtual MIDI ports (IAC, loopMIDI-style apps) fed hand-crafted byte streams; aggressive SysEx interleaving with running status. Rarely if ever caused by correct Java code — it is a driver/data problem surfaced by the JDK parser.
Related errors
- %s: %d->Invalid message: message status=0x%X while sending s
- %s: %d->internal error: sysex message status=0x%X while send
- Error: Out of memory in ADLC\n
- %s: Found %d syntax error
- %s: Found %d semantic error
AI-assisted analysis of openjdk/jdk@88dfb74bbe (2026-08-14).
Data as JSON: /api/errors/76aca2d5838011a8.
Report an issue: GitHub.