SIGFPE crash on import score generated from PDF converter, both in 2.2 and master

• Mar 29, 2018 - 05:11

Happens in both 2.2 or 3.0 nightly f9effba. Open attached score and get SIGFPE (Arithmetic exception). The faulting line in 2.2 is in Fraction += operation in fraction.cpp::188

  _numerator = _numerator * (tmp / _denominator) + val._numerator * (tmp / val._denominator);

because for some reason val's denominator is 0. The full 2.2 stack trace is:

1 Ms::Fraction::operator+= fraction.cpp 118 0x555556666515
2 Ms::TimeSigMap::normalize sig.cpp 247 0x555556661462
3 Ms::TimeSigMap::add sig.cpp 220 0x555556661335
4 Ms::Measure::read measure.cpp 1817 0x5555564edfb4
5 Ms::Score::readStaff scorefile.cpp 334 0x555556652a93
6 Ms::Score::read scorefile.cpp 990 0x555556656dd5
7 Ms::Score::read1 scorefile.cpp 935 0x5555566569a4
8 Ms::Score::loadCompressedMsc scorefile.cpp 783 0x555556655afe
9 Ms::Score::loadMsc scorefile.cpp 830 0x555556655e2a
10 Ms::readScore file.cpp 2103 0x55555608002d
11 Ms::MuseScore::readScore file.cpp 343 0x5555560705b2

Attachment Size
i_wont_forget.mscz 19.81 KB


Happens in the 27th iteration of TimeSigMap::normalize()'s loop.

BTW, I know can't expect musescore to import bad files of course. But it shouldn't crash. it should fail gracefully, and with a qDebug message.

tm got set to 0 in the iteration prior to the crash:

tm   = ticks_measure(e.timesig());

So I'm guessing that means that e.timesig() had a numerator of 0 somehow. So maybe there should be a sanity check for numerator of timesig's to never be 0?

Do you still have an unanswered question? Please log in first to post your question.