Memory leak in MidiKeyboardState?


#1

I think I spotted a memory leak in MidiKeyboardState (at least on Windows - did not test with OS/X yet).

Seems to happen when the midi buffer contains midi events that are not note on/off events (e.g. meta events)

I’m not entirely sure when I first started seeing this but I guess it was after upgrading from Juce 4.1 to 4.2.3

can be reproduced by creating a vanilla console application and inserting following code into main()

the code reads a midi file and copies it entirely to a large dummy midi buffer (don’t ask me why, this is just a way to condense my real-world application to the simplest repro case possible)

make sure the midi file you use contains some meta events (eg track names) !
I’ll be happy to send you the projucer project with a suitable midi file - just let me know

int main (int argc, char* argv[])
{

const double samplesPerSec = 44100.0;
const double ticksPerSec = 96.0;
const double samplesPerTick = samplesPerSec / ticksPerSec;

String fileName = File::getCurrentWorkingDirectory().getParentDirectory().getParentDirectory().getFullPathName() + “/greensleeves.mid”;
File file(fileName);
jassert(file.existsAsFile());
FileInputStream fStream(file);

MidiFile from;
from.readFrom(fStream);

auto track = from.getTrack(0);
int greatestSamplePosEncountered = 0;
MidiBuffer destBuffer;

for (int i=0; i< track->getNumEvents(); ++i)
{
auto eventPtr = track->getEventPointer(i);
int eventTick = eventPtr->message.getTimeStamp();
int samplePos = eventTick * samplesPerTick;
if (samplePos > greatestSamplePosEncountered)
{
greatestSamplePosEncountered = samplePos;
}

destBuffer.addEvent(eventPtr->message, samplePos);

}

MidiKeyboardState keyboardState;
keyboardState.processNextMidiBuffer(destBuffer, 0, greatestSamplePosEncountered, true); // MEMLEAK OCCURRING HERE!?

return 0;
}

following output observed in Visual Studio:

JUCE v4.2.3
Detected memory leaks!
Dumping objects ->
{1393} normal block at 0x01EBCC30, 7 bytes long.
 Data: < X   $ > FF 58 04 03 02 24 08 
{1392} normal block at 0x01EBCAE0, 7 bytes long.
 Data: < X   $ > FF 58 04 03 02 24 08 
{1391} normal block at 0x01EBC680, 6 bytes long.
 Data: <   gre> FF 03 0D 67 72 65 
Object dump complete.