Crash on opening this score

• Apr 12, 2019 - 17:20
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

3.1 Beta.

Open attached score, result: crash.

I'm working on a fix for this.

Attachment Size
RachmaninovPianoConcerto2.mscz 216.42 KB

Comments

• Apr 13, 2019 - 11:24

Actually the file doesn't seem to be exactly corrupted, it correctly loads in MuseScore 3.0.5 despite some strangely located hairpins which now cause this crash. The reason why it is reported as corrupted in master is the tick-fraction transition. The file contains a lot of <location> tags inside measures, and they seem to cause problems sometimes due to integer tick rounding errors. Werner and @mattmcclinch added the commit to compensate these problems but it seems not to help in this case just because Fraction::ticks() function works incorrectly with negative numbers. I wonder how did it go unnoticed for so long, and don't really understand how exactly can this cause MuseScore report measures being 1.5 times longer than they are, but correcting the Fraction::ticks() calculation makes this file load correctly like it was in version 3.0.5 (provided the patch for the crash is applied).

I opened a pull request with the Fraction::ticks() correction but I am not sure whether this change can cause any undesired effects: https://github.com/musescore/MuseScore/pull/4909.

Reply

• Apr 14, 2019 - 05:57

To explain, the hairpins are intentional. I created rests in an invisible 3rd voice so that I could play hairpins in such a way that they both properly reflect where they should be on the score, and so that when 3.1 releases they have the proper playback as well; that is to say, that any cresc/dim effect does not necessarily take place at the beginning of the playing of a note.

If I had to guess, the actual issue might be related to the fact that for some of these measures, I deleted some of the 3rd voice rests, such as those at the beginning of measures that weren't needed for the sake of hairpin placement. I did test this in 3.1 (using invisible rests to delay a cresc/dim effect until a specific point in a measure) and it did work, so my suspicion is that it's those deleted rests that are causing the problems.

Reply

Fix version
3.1.0