crash when selecting corrupt measure

As you probably noticed, the export of this file in XML format solves this issue:
- Tenorh_2.xml
- Tenorh_2'.mscz (with visible rests)

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

in Selection::updateSelectedElements() the assignment of

int stick = startSegment()->tick()

results in crash because startSegment() is NULL.

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.

Interestingly, if I delete all other measures except the problematic ones in 2.1, and then export to MusicXML (Tenorh_problem-measures.xml) and then reimport, I get:

Which has interestingly inserted invisible rests.

However, if I instead had just exported to .mscx (Tenorh_problem-measures.mscx) and then open that, I get:

And selecting that first measure gives the same segfault and stack trace.

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.

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())
                              deselectAll();
                  _selection.setRange(m->tick2segment(tick),
                                      m == lastMeasure() ? 0 : m->last(),
                                      staffIdx,
                                      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.

Agreed

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!!

The import file was attached tiff file (which I've packed into zip format).

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.

@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,
Ralf

OK. When reporting issue in the future, try to provide exact reproduction steps using a single version.