MidiMessage segmentation fault

[Untero]

I was porting an application to a Linux platform (Ubuntu 16.04) and noticed something was wrong with reading MidiMessage properties.

Everything functions as good as windows/mac versions does.
However, whenever I try to access MidiMessage instance, I catch a segmentation fault. Looks like I’m accessing memory where I shouldn’t do it.
Using MidiMessage::getTimeStamp() returns gibberish or zero, using isNoteOn() and other functions gives a segmentation fault. getRawData() is where error occurs.
Could that be a freshly build .so library problem?

[Untero]

I was hoping I’ve made an error in my app, but after running a simple program I’m pretty sure it’s not my fault.

 juce::File ReadFile("/home/untero/midi/P.mid");

 juce::FileInputStream* FileStream = ReadFile.createInputStream();

 juce::MidiFile * MidiFile = new juce::MidiFile();
 if (!MidiFile->readFrom(*FileStream))
      return 0;

 for (int j = 0; j < MidiFile->getNumTracks(); j++)
 {
      const juce::MidiMessageSequence* CurrentTrack = MidiFile->getTrack(j);
      for (int i = 0; i < CurrentTrack->getNumEvents(); i++)
      {
          juce::MidiMessageSequence::MidiEventHolder* meh = CurrentTrack->getEventPointer(i);
          if (meh->message.isNoteOn())
                 qDebug( "NoteNumber %d Timestamp 0x%05x ", meh->message.getNoteNumber(), meh->message.getTimeStamp());
      }
 }

All MidiFile and MidiMessageSequence works fine, but midi messages in the sequence are garbage no matter what file I upload.

NoteNumber 62 Timestamp 0x4015b0
NoteNumber 62 Timestamp 0x4015b0
NoteNumber 66 Timestamp 0x4015b0
NoteNumber 66 Timestamp 0x4015b0
NoteNumber 68 Timestamp 0x4015b0
NoteNumber 68 Timestamp 0x4015b0
NoteNumber 69 Timestamp 0x4015b0
NoteNumber 69 Timestamp 0x4015b0
NoteNumber 69 Timestamp 0x4015b0
NoteNumber 69 Timestamp 0x4015b0
NoteNumber 69 Timestamp 0x4015b0

[jules]

The timestamp is a double.

(This is a why modern C++ discourages use of printf…)

[Untero]

Here’s C++ version of it. qDebug() << "Timestamp: " << meh->message.getTimeStamp();
first file

Timestamp: 5.7576e+228
Timestamp: 5.7576e+228
Timestamp: 5.7576e+228
Timestamp: 5.7576e+228
Timestamp: 5.7576e+228
Timestamp: 5.7576e+228
Timestamp: 5.7576e+228
Timestamp: 5.7576e+228

second file

Timestamp: 2.59824e-317
Timestamp: 2.59824e-317
Timestamp: 2.59875e-317
Timestamp: 2.59875e-317
Timestamp: 2.599e-317
Timestamp: 2.599e-317
Timestamp: 2.59913e-317

[jules]

Did you call convertTimestampTicksToSeconds()?

[Untero]

No, there is nothing behind this code.
Running exact same code on windows give proper result:

Timestamp: 0
Timestamp: 720
Timestamp: 960
Timestamp: 1440
Timestamp: 2400
Timestamp: 2460
Timestamp: 2520
Timestamp: 2640

[jules]

Well that’s very peculiar, there’s nothing platform-specific happening… The time is read in MidiFile::readNextTrack, line 301, maybe step into it and see how come it’s getting junk data?

[Untero]

Messages created at readNextTrack are constructed with valid params, no junk data detected. I would try to track moment where it turns gibberish.

[Untero]

Jules, I’m a bit lost, I have no idea what is going on here…

[Untero]

Does it look like a shared object problem?
Inside MidiFile::readNextTrack()

Inside MidiMessageSequence::addEvent()

Inside MidiMessage::getTimeStamp()

I don’t know why is it corrupting memory when accessing MidiMessage.

[jules]

I can’t see anything wrong with the code that reads and adds those messages. Most likely the problem is somewhere else, e.g. you’ve managed to delete the MidiFile or MidiMessageSequence before trying to read from it, so are looking at dangling memory.

[Untero]

Okay, as supposed, that was fairly stupid one.
While using up to date shared object, I was using old headers on my project.