openjdk/jdk · error

%s: %d->Invalid message: message status=0x%X while sending s

Error message

%s: %d->Invalid message: message status=0x%X while sending short message

What it means

Emitted by the macOS CoreMIDI MIDI output port when MIDI_OUT_SendShortMessage receives a short message whose status byte falls into the 0xF0..0xF7 system-common range but is not one of the recognized codes (only Song Position Pointer 0xF2 needs 3 bytes and Tune Request 0xF6 needs 1 are handled). The native switch hits its inner 'default: Invalid message' branch, sets byteIsInvalid, and the function returns -1 without sending anything to the endpoint. It is a data-validation error in the status-byte dispatch table of PLATFORM_API_MacOSX_MidiOut.c.

Source

Thrown at src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiOut.c:156

                    break;
                case 0xF3:    // Song select
                    //fprintf(stderr, ">>>MIDI_OUT_SendShortMessage: Song select....\n");
                    nData = 2;
                    break;

                case 0xF2:    // Song position pointer
                    //fprintf(stderr, ">>>MIDI_OUT_SendShortMessage: Song position pointer....\n");
                    nData = 3;
                    break;

                case 0xF6:    // Tune request
                    //fprintf(stderr, ">>>MIDI_OUT_SendShortMessage: Tune request....\n");
                    nData = 1;
                    break;

                default:
                    // Invalid message
                    fprintf(stderr, "%s: %d->Invalid message: message status=0x%X while sending short message\n",
                            __FILE__, __LINE__, data[0]);
                    byteIsInvalid = TRUE;
                    break;
            }
            break;
        }

        default:
            // This can't happen, but handle it anyway.
            fprintf(stderr, "%s: %d->Invalid message: message status=0x%X while sending short message\n",
                    __FILE__, __LINE__, data[0]);
            byteIsInvalid = TRUE;
            break;
    }

    if (byteIsInvalid) return -1;

    MIDIPacketListAdd(packetList, sizeof(mBuffers), packet, 0, nData, data);

View on GitHub (pinned to 88dfb74bbe)

Solutions

  1. Validate the status byte on the Java side before send(): reject anything outside 0x80-0xEF plus 0xF2/0xF6 for short messages on macOS
  2. Send system-realtime bytes (0xF8-0xFF) only — they are handled; route other system-common messages through SysexMessage/long-message APIs
  3. Check your message construction: use ShortMessage.setMessage(command, channel, data1, data2) rather than setMessage(status) with raw status ints
  4. If you must send 0xF1/0xF3, wrap the send and ignore the -1 return plus stderr line, or use a different MIDI backend

Example fix

// before
int status = 0xF1; // MIDI Time Code quarter frame
msg.setMessage(status, 0, 0);
receiver.send(msg, -1); // macOS: prints 'Invalid message ... 0xF1', returns -1

// after
int status = 0xF1;
if (status == 0xF2 || status == 0xF6 || (status >= 0xF8 && status <= 0xFF)
        || (status >= 0x80 && status <= 0xEF)) {
    msg.setMessage(status, 0, 0);
    receiver.send(msg, -1);
} else {
    // system-common not supported as a short message here; skip or log
}
Defensive patterns

Strategy: validation

Validate before calling

// before receiver.send(msg, -1)
private static final int REALTIME_MIN = 0xF8;
static boolean isSupportedShortStatus(int status) {
    return (status >= 0x80 && status <= 0xEF)      // channel voice
        || status == 0xF2 || status == 0xF6        // song pos, tune request
        || (status >= REALTIME_MIN && status <= 0xFF); // realtime
}
if (!isSupportedShortStatus(msg.getStatus())) {
    // log and drop instead of native 'Invalid message' + return -1
}

Prevention

When it happens

Trigger: Calling javax.sound.midi.Receiver.send() / MidiDevice.getReceiver().send() with a ShortMessage whose status is an unhandled system-common byte such as 0xF1 (MIDI Time Code), 0xF3 (Song Select), 0xF4, 0xF5 (undefined), or 0xF7 (EOX) as the leading byte; also any 0xFn byte the switch did not map. Occurs only on macOS because the dispatch logic is platform-specific.

Common situations: Hand-built Sysex/short-message byte arrays passed through ShortMessage.setMessage(int,...) with raw ints; porting MIDI code from Windows (where the win32 MM API accepts these bytes) to macOS; test fixtures that iterate over all 0x80-0xFF status values; misinterpreting running-status data where a data byte is mistakenly used as status.

Related errors

AI-assisted analysis of openjdk/jdk@88dfb74bbe (2026-08-14). Data as JSON: /api/errors/23e34078bc987c53. Report an issue: GitHub.