SIGFPE crash on import score generated from PDF converter, both in 2.2 and master
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 |
Comments
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:
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?
If in Measure::read(XmlReader& e, int staffIdx) I check for _len == 0, then I can complete import of the XML without crashing:
https://github.com/ericfont/MuseScore/commit/3734ac382d1d7a80d88f5e2161…
But of course the resulting score is garbage. There is a probably better way to catch this problem and report to user. Maybe some sanitation test earlier. But I don't know the proper way to do this.