Crash on save after creating new part from score with connecting barlines with parts selected in bottom-to-top order

• Dec 20, 2015 - 15:42
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore
Tags
2.0.3

To reproduce, open attached score, go to File -> Parts, click New, check boxes for more than one instrument in bottom-to-top order (e.g., check Viola, Violin II, Violin I), click OK, then attempt to save, or wait for the autosave. MuseScore crashes, and the autorecovery file is corrupted. This can be reproduced with any score with linked parts.

Issue exists in released 2.0.2 and c012358.

Attachment Size
partscrash.mscz 19.36 KB

Comments

• Dec 20, 2015 - 18:20

Right, I can reproduce.

All we need to do is create a new part and check Violin II, then Violin I. When saving, it seems to crashes because the staves are inverted. Violin II is over Violin I (the the new part score).

If we check violin I before Violin II, everything works.

I don't know if there's an easy way to sort the linked staves to add them to the new part in the right order.

But the solution lies in excerptsdialog.cpp in function createExcerptClicked.

// a new excerpt is created in AddExcerpt, make sure the parts are filed
for (Excerpt* ee : e->oscore()->excerpts()) {
if (ee->partScore() == nscore) {
ee->parts().clear();
ee->parts().append(e->parts());
}
}

Reply

• Jan 12, 2016 - 21:52
Title Crash on save after creating new part with parts selected in bottom-to-top order ⇒ Crash on save after creating new part from score with connecting barlines with parts selected in bottom-to-top order

Reply

• Mar 28, 2016 - 02:31

I suppose I was ambiguous just now. I'm referring to the crash backup/autosave—the "MuseScore quit unexpectedly. Restore previous session?" file. This bug leads to that file being reduced to a few bytes and unopenable, even in c6ab148.

Reply

• Mar 28, 2016 - 02:56

OK, I can imagine the auytosave file might be corrupt in this case, but your original file should never be destroyed. If you have steps that destory the actual score, do post those, but as far as I know, that is no longer a problem. Merely having a bogus auto-save file is unfortunate, but not the end of the world.

Reply

• Mar 29, 2016 - 07:58

Do we really want the ability to have a different order of instrument in parts?
If yes, I guess we need a better UI... In the meantime, I think I will disallow this and make sure the instruments in the parts are in the same order than in the score, at least at creation time...

Any opinion?

Reply

• Mar 29, 2016 - 12:06

I see two ways of fixing this.

1/ We make sure the span doesn't go over the number of staves
2/ We make sure that parts have the same instrument order than score at part creation time.

So again, does anyone rely on the fact that we can generate parts in the order they instrument are clicked in the part dialog? If not, we can go for 1/, if yes, let's go for 2...

Reply

• Mar 29, 2016 - 12:08

are the instruments in the parts getting reodered, if they get reordered in the parent score?
Can instruments get reodered in part, independantly of parent score?

Reply

• Mar 29, 2016 - 13:41

As of today,

Are the instruments in the parts getting reordered, if they get reordered in the parent score
No

Can instruments get reordered in part, independently of parent score?
No

Reply

• Mar 29, 2016 - 13:49

Which means if you want them in a different order in parts than score, you'd have to add them in that order on part Generation.
May make sense on occasions? But maybe surprising and unwanted in much more cases, so maybe better disallow it altogether for now, and maybe later (i.e. not in 2.0.3) allow reordering?

Reply

• Mar 29, 2016 - 15:45

FWIW, I am happy to see us disallow having instruments in a different order between part and score. Seems like allowing that is asking for trouble. Today it's barline span, tomorrow it's brackets, then it's, oh, maybe staff spacing due to lyrics or something else.

Reply