crash when changing a triplet's rest's duration

• Feb 28, 2019 - 12:10
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
PR created
Regression
No
Workaround
Yes
Project
  1. In the attached score (taken from another issue) go to measure 49 in Electric guitar
  2. Select the quarter rest in the triplet
  3. Press 4

Expected result: it changes into an 8th rest (actually 2 of them)
Actual result: crash

Stack trace:
1 Ms::Element::setParent element.h 178 0xd915d4
2 Ms::Score::undoAddCR edit.cpp 4556 0x86cfe0
3 Ms::Score::addRest edit.cpp 176 0x853e62
4 Ms::Score::setRest edit.cpp 350 0x854d1e
5 Ms::Score::changeCRlen cmd.cpp 1150 0x9db98d
6 Ms::Score::changeCRlen cmd.cpp 1101 0x9db4b1
7 Ms::Score::padToggle score.cpp 2765 0x92a00b
8 Ms::Score::::operator()(void) const cmd.cpp 3593 0x9e644e
9 std::_Function_handler>::_M_invoke(const std::_Any_data &) std_function.h 316 0x9f301a
10 std::function::operator()() const std_function.h 706 0xeec162
11 Ms::Score::cmd cmd.cpp 3678 0x9e92af
12 Ms::ScoreView::cmd scoreview.cpp 2321 0x424251
13 Ms::ScoreView::cmd scoreview.cpp 1761 0x4209b1
14 Ms::MuseScore::cmd musescore.cpp 6168 0x4db957
15 Ms::MuseScore::cmd musescore.cpp 5639 0x4d87f2
16 Ms::MuseScore::qt_static_metacall moc_musescore.cpp 855 0x78130b
17 QMetaObject::activate(QObject *, int, int, void * *) 0x68a9321a
18 Ms::ScoreTab::actionTriggered moc_scoretab.cpp 225 0x78992e
19 Ms::ScoreTab::qt_static_metacall moc_scoretab.cpp 110 0x7893b6
20 QMetaObject::activate(QObject *, int, int, void * *) 0x68a9321a
...

Happens in (at least) MuseScore 3.0.2-4 as well as in current master

Attachment Size
Smooth-Santana.mscz 96.71 KB

Comments

Somehow the Electric Guitar part (and possibly others, who knows?) got out of sync with the master score. To correct this, go to File->Parts... and delete all of the parts, one by one. Then press "New All" and "OK". This will regenerate all of the parts, and MuseScore will no longer crash if you change the duration of the rest.

I don't know if we'll ever know that. Another workaround is to cut the measure and paste it back. This would be useful if much effort had gone into fine tuning the excerpts after they had been generated.

By the way, what is the other issue from which this score was taken?

After looking at the score's XML data embedded in the compressed save file I understand now exactly what you mean by the part getting out of sync with the master score.

What is the justification for saving the measure data twice in the XML? I seems to me that the main score measures could instead be generated from the individual parts.

There are items independent in the master score and parts. If this were not so, not every score has parts, so it would be more logical for all parts to be created from the master score.