crash when selecting corrupt measure

• Apr 25, 2017 - 08:29
Reported version
S2 - Critical

Came up in, a score converted from PDF tp XML, then imported into MuseScore 2.0.3.
MuseScore reports a corruption:
Measure 50 Staff 1 incomplete. Expected: 4/4; Found: 5/8

Measure 50 is actually 49, because the 1st measure is ignored from measure cound (but not really a pickup measure)
Now selecting just that measure 50 (or 49) causes a crash, in 2.0.3 as well as in 2.1-RC and the latest 2.1 nightly, but not on the latest selfbuild from master, which doesn't even complain about a corruption, that instead seems to have 'autocompleted' that measure, with a leading quarter rest and an 8th rest before the quarter note.

Attachment Size
Tenorh.mscz 22.17 KB


I can verify crash on latest 2.1 with stack trace:

1 Ms::Segment::tick segment.cpp 768 0x12ae0b5
2 Ms::Selection::updateSelectedElements select.cpp 496 0x12b3a4d
3 Ms::Score::selectRange score.cpp 3049 0x12a055a
4 Ms::Score::select score.cpp 2834 0x129f608
5 Ms::Score::selectSingle score.cpp 2853 0x129f69f
6 Ms::Score::select score.cpp 2832 0x129f5db
7 Ms::ScoreView::select scoreview.cpp 3681 0xa75814
8 Ms::SelectTransition::onTransition scoreview.cpp 473 0xa87f1d

and according to what you say in description, it sounds like this is still a problem in master even though master doesn't complain:

Now selecting just that measure 50 (or 49) causes a crash, in 2.0.3 as well as in 2.1-RC and the latest 2.1 nightly, but not on the latest selfbuild from master, which doesn't even complain about a corruption, that instead seems to have 'autocompleted' that measure, with a leading quarter rest and an 8th rest before the quarter note.

I think master reconstructs the file (read: adds some rests) using the tick values in the score, but I'm not sure

Another way to fix the file is to select the prev measure, shift select the broken, and swap voices 1 and 2 twice

Jojo, I now have the question: should we fix .mscx loading code to "autofill" with invisible rests, or should we allow such a bad measure to be loaded and instead prevent the crash from occurring? Or do both?

I wasn't invited to the conversation, but the questions is, are the rests in the correct spot, or are they inserted in some pseudo random manner. If they are correct, then keep them, if it is not know then prevent the crash and let the user fix it. I would prefer to get the measure corrupt error so I can figure out what wrong with it than to find out later that MuseScore added its own rests.

@eric: why invisible rests? master fills with visible rests. But I guess we need to cross-check with the XML and even with the PDF that stemmed from.
@mike: exactly

As I said the crash results from _startSegment being NULL. It seems _startSegment is assigned NULL in this block in Score::selectRange():

            if (_selection.isNone()
               || (_selection.isList() && !_selection.isSingle())) {
                        if (_selection.isList())
                                      m == lastMeasure() ? 0 : m->last(),
                                      staffIdx + 1);

because m->tick2segment(tick) returns NULL. So that sounds like the problem is because that first tick doesn't contain any segment. So possible way to fix this is to test if tick2segment is NULL and if so bring up a big error message. Or something else?

Jojo why invisible rests?

Well it seems that those rests weren't actually part of the original XML file. So therefore auto-filling with invisible rests seems to be an entirely appropriate thing to do. I would actually suggest that the .mscx do the same thing...fill with invisible rests. Anyway, I can still produce this crash even though it is not the original persons XML file, so I think I at least have something that needs to be fixed.

@mike320, I think that MuseScore import should definitely complain when it tries to import this corrupt measure. The invisible rests seem like they are in the correct position, and seem to be something which musescore's export to XML added because it realized that there were no rests at those segments but needed to have some rests to account for the lack of tick at first position. And MuseScore 3.0 apparently just added these rests when really it shouldn't have added them without complaining.

What I think needs to happen is for MuseScore to both complain on import as well as be nice by adding some extra *invisible* rests to account for the lack of needed rests in the original file. That way user can actually select the problematic measure without a crash, so user can actually fix the problematic measure.

First of all many thanks to you guys working on that issue.

You asked for the history of this issue:
1. I scanned a single sheet note and imported it as tiff file with "smart score lite 6" into "Finale print music 2011a"
2. Next I exported the result as Music XML format (see attachment)
3. And last I imported it into MuseScore 2.0.3 and tried to correct the issues I noticed

Hope this helps.
I will continue working on the sheet considering the hints, you gave.
Thanks again for your extensive help and support!!

Attachment Size
KeinName1.xml 86.06 KB

OK, so there are actually notes gotten lost, at the places where the repair inserted rests, the questionable measure should have looked like this:

Importing that XML though (in MuseScore 2.1-RC) gives an entirely different result, not corrupt, not causing a crash.
So either you did something to the score in between or the issue is fixed in 2.1?

Attachment Size
KeinName1.mscz 20.5 KB

There are several measures in the file Jojo uploaded that have altered durations such as actual measures 45, 50 and 53. This is only a partial list. Also, the measure you are displaying is measure 52 in the uploaded score and lacks all slurs and accents when I open it in my 2.1-RC version.

Status (old) active needs info

@mike320, the fact that some of the measures in rschaefer's xml do not match the tiff file is not a problem...that is not MuseScore's fault, but rather is just a realistic limitation of the pdf->xml converter program which rscahaefer used. Just for reference, I notice a few measures that the xml file are incomplete when I first imported into MuseScore:

Meas 27 (26 in tiff):

Meas 29 (28 in tiff):

Meas 44-46 (43 in tiff):

Meas 50 (47 in tiff):

Meas 53 (50 in tiff):

and the ending. And of course there are slurs and articulations missing. I should note the long slur from meas 30 to meas 32 is not musescore's fault, but rather the XML file's fault cause it has a tie "start" without a corresponding tie "stop". Anyway, none of these are MuseScore's fault, since musescore appears to read the XML correctly.

I would very much like rschaefer to provide the exact replication steps using the latest 2.1 nightly (don't mix versions) that start with the KeinName1.xml file and says what exact operations were done to produce the problematic measure. But in the meantime, I'm going to mark this issue as "needs info" since without knowing the exact steps I don't know how to best resolve this issue.

I'm sorry, I cannot reproduce this issue neither with build 2.0.3 or with nighly build 2.1. The only thing, I remember is that I started correcting the incomplete measures and thereafter I entered the missing music notes.

Thanks for your support,