Crash when reading some Midi Files


When trying to read some Midi files, Juce crashes.
3am03.mid.cpp (40.6 KB)

I attach one of the involved Midi files. (changed the extension that it uploads)

It sometimes raises two or three of the below exceptions. The two jassert are raised in juce_MidiMessage.cpp, and the third one in juce_ByteOrder.h. When not raised, I got some midi messages (never the same number) with negative timestamps, as if not initialized.
I tried with and without a pointer for the FileInputStream, for the same result.
Also, the code works fine with plenty of other midi files.

![image|658x235] (upload://ko05AkgVhHjjK5ch9CZD4QagaYp.png)

This file opens fine with a DAW (tested with S1 and reaper)

Any idea what to fix here?

No answer on that one from the Juce team? :frowning:
Don’t know how I could be more accurate in the issue, provided the 2 lines of code and the Midi file which has the issue.


@Rachmaninov the following code works for me here. maOS 10.14.5.

juce::FileInputStream stream (juce::File ("/path/to/file/3am03.mid"));
juce::MidiFile midiFile{};
if (midiFile.readFrom (stream) && midiFile.getNumTracks() > 0) {
    auto numTracks = midiFile.getNumTracks();
    for (int i = 0; i < numTracks; ++i) {
        auto midiTrack = midiFile.getTrack (i);
        for (auto e : *midiTrack) {
            DBG (e->message.getDescription());
1 Like

Hello hhit,
Your code gives us the same error (Windows10). :frowning:

I get similar errors, beginning with track 8. Might be that this track contains some corrupted data that Juce can’t handle gracefully, i.e. show an error or just skip instead of crashing.

What’s the origin of the file? In the daws you’ve tested, what does the midi content look like?

The content looks normal to me in a DAW but I guess there is something wrong in these files. However, of course, it should not crash !

FWIW I made a couple of plugins that read Midi files - when I try to read your they also crash. I’ll see if I can debug this (but that’s not high on my todo list).

Maybe it’s Roli’s job to fix their bugs? :roll_eyes:

There’s something wrong with the MIDI file… MIDIKit fails to load it:

6/12/19 1:55:39 AM ~/Desktop/3am03.mid [ERROR# -39 while opening]


Yes, but it should not crash.

The code you’re pointing out is NOT a crash. It’s an assertion.

Does it actually crash if you continue (i.e. what would happen in a release buid)?

Or does it just carry on and load as much as it can from this obviously broken MIDI file, just like any other host would?

Hello Jules,

Of course it crashes in a release build, otherwise I would not have opened the thread.

Frankly I have not run this in a debugger yet - I’ll try and do that tonight. I overlooked the assertion - that points to a corrupted file really - a negative note number or one above 128.

I have loaded tons of Midi files using Juce and never had a crash, so the comment like Roli should fix their bugs seems out of line.

One of the track length chunks in the file is incorrect which was causing JUCE’s midi file parsing to fall over. I’ll push a fix shortly.

Thank you :wink:

1 Like

Hello there,
Found 3 new files that make Juce crash :wink:
ba_bran3.mid.cpp (122.7 KB) dixie-nw.mid.cpp (12.5 KB) Impersong.mid.cpp (17.0 KB)

Thanks for raising this issue and providing some useful test cases. I’ve pushed some fixes here:

Just to avoid any ambiguity, it’s probably worth pointing out that all of those new files are malformed. A couple have incorrect track lengths, and one has an incorrect header length. Therefore, they will still fail to load, although they will no longer cause a crash.