Crash after copy-paste linked measures before a system change with multimeasure rests

• Mar 26, 2016 - 15:57
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore
Tags
2.0.3

GIT commits d349682 and 7a3ca25 / Windows7

1) "My First Score"
2) Enter a whole note in the first measure -> Exit note input mode
3) Press "M", for enable multimeasure rests.
4) "I" -> Add a linked staff -> Ok
5) Select the first measure of the linked staff (bass clef)
6) Copy-paste three times this measure, or, faster: press "R" key three times

So far, so good. But you've noticed the first break line has appeared. You are at the critical point.

The picture below has been produced with a minimal test file, with an added break line. This one (similar steps, but only copy-paste twice, at step #6): four measures break line.mscz
critical point.jpg

6) Press again "R" key, or copy-paste again.

Result: crash

Comments

• Mar 26, 2016 - 16:31

Additional notes:

1.The sequence order of the steps #3 and #4 is strictly necessary to get this crash.

2. The crash only occurs when you apply the copy-paste from the added linked staff, no from the original staff.

3.In "My First Score", if you delete, first, all the default break lines, and then you apply the same steps (and copy-paste x times), the crash will occur in mid-score (measure 18) during the layout change (with the creation of a second system)

- With preliminar tests, with quasi-similar steps (don't me ask why I entered only quarter rests! It was just for testing something...) :)

So, I got some crashes, but I also got a corrupted score, probably related to the current issue? Indeed, you notice it's occurs also at mid-score, just before a break line and mm-rests.
This file : My_First_Score1.mscz

4. With the second one (and always with these testings steps and similar file configuration), I get a score, not corrupted, but with a total of 31 measures... A measure has disappeared.
This file: My_First_Score2.mscz

EDIT: same issue with the 2.0.2. But only by using copy-paste at step #6. By using R key, it was an other issue (fixed, with a single staff only)

Reply

• Mar 26, 2016 - 17:14

Good new: I cannot reproduce on March, 2014 and early July 2014. So, should probably be able to locate the change, or approach it. With a little patience!

EDIT: well, more complicated as wished :(
Eg, it work in beginning August 2014, but I receive a crash at step #4 in beginning September.
And another crash in October, but with complete steps.
And again crashes at step #4 on November (and December)

Further investigation needed, I fear.

Reply

• Mar 26, 2016 - 18:37

First result:
As said, it works in August 2014, until August 16.
It is broken on August 17 (and from the step # 4), presumably with this commit: https://github.com/musescore/MuseScore/commit/1886d6d9114bfc31c1e162123…
For fix: #29796: Crash on deleting all notes from part with mmrests; corruption on undo when doing same in score

Now I have to figure out why and when the crash comes only in October with full steps. And why, it is broken again from the step #4, between November 2014 and March 2015. Month from which, again, it is necessary to apply all the steps, the current behavior.
Much things.

Reply

• Mar 26, 2016 - 20:13

Next results:

1) On September 17, 2014, probably with this commit: https://github.com/musescore/MuseScore/commit/0c226eee31c5c1e9f4e96367d…,
for fix: #33411: Adding Instrument to score with multi-measure rests enabled crashes MuseScore, it's needed to apply all the steps to receive the crash.

2) On November 20, 2014, again, the crash occurs from the step #4.
All steps necessary with this nigthly: 0a913fd
Crash from step #4 with these one: 3e73dc5 and 08e2faa

Unfortunately, this day, after a first checking, I can't find clearly where is located this new change.

Reply

• Mar 26, 2016 - 20:12

Last episode:
It is again necessary to apply all steps to receive the crash from February 9, 2015 (and so, is the current behavior), most likely with this commit: https://github.com/musescore/MuseScore/commit/0056b0978ca12f0e7493844cc…
For fix: #42391: A time signature change in a part with MM rests corrupts the last measure and leads to a crash

Conclusion: seems that the main cause is due to the commit on August 17, 2014, see comment #3.

And that's all for today :)

Reply

• Mar 28, 2016 - 07:47
Title Crash after copy-paste a linked measure/staff, involving break lines and multimeasure rests ⇒ Crash after copy-paste linked measures before a change systeme with multimeasure rests

Attempt to a better title. With a variation of this issue for illustrution:

1) "Treble clef template"
2) Add a note in measure 17 (just before the second system)
3) Exit note input mode, and press "M"
mm.jpg
4) "I" -> Add a linked staff -> Ok
5) Copy-paste the measure 17 of the second linked staff into the "measure 18" (the following mm-rests), or press R key

Result: crash

Reply

• Mar 28, 2016 - 07:54
Title Crash after copy-paste linked measures before a change systeme with multimeasure rests ⇒ Crash after copy-paste linked measures before a system change with multimeasure rests

Reply

• Mar 28, 2016 - 14:29

Systematic crashes here on Win7 and Win10 (EDIT: and confirmed with 66d75ccp.) With eg the steps on comment #7.

Recall: you must select the measure of the LINKED STAFF (no issue with the top staff) and press R key, or copy-paste in the following mm rests (and always in the same second linked staff)

- And take care to read this (in particular points 3 & 4) : https://musescore.org/fr/node/103646#comment-464641, with the two "instructives" attached .mscz files (with corruption eg)

crash.jpg

- And result with the steps in the initial message with "My First Score" (Repeat four times the first measure of the linked staff always)

first score.jpg

Reply

• Mar 28, 2016 - 14:38

I don't see the crash using the steps from #7 either, but if location of system breaks is part of the trigger, then I can't reproduce your steps because for me, the seocnd system starts with measure 19 - 17 is not just before the system break. I guess that's because my page size is Letter instead of A4. If I add a note to measure 18 (the measure before the break), the measure moves to the next system.

So I tried changing the page size to A4 and repeating your steps. This time measure 17 is indeed the last measure of the first system, and adding a note does not move it to the next system. But following these steps still does not crash for me (Ubuntu 14.04).

No crash with the steps in the original message either.

Reply

• Mar 28, 2016 - 15:34

Indeed, I use a A4 page size.
So, steps with a Letter page size:

1) "Treble clef template"
2) Layout -> select Letter page size -> OK
3) Add a note in measure 18 (just before the second system)
Result: indeed, the measure moves to the next system. So:
4) Add a break line to this measure 18
Next result: a third system is created
5) Press "M"
6) "I" -> Add a linked staff -> Ok
7) Copy-paste the measure 18 of the second linked staff into the "measure 19" (the following mm-rests), or press R key

Final result: crash

EDIT: well, I reproduce also constantly in the Letter page size without the step #4 (add break line)
mesure 19.jpg

Reply

• Mar 28, 2016 - 16:28

Very surprised by your fails.
Yes, as usual (I think you know me now!), I use always the latest nightlies for the tests.
And currently, I can reproduce all the times this issue with 66d75cc
and Windows 10.
Ditto after a RevertToFactorySettings.
I go trying under Win 7 with this latest nightly: would be surprised not to have the same result. But I will check.
And you, are you using your own builted nightlies, or those downloaded from the website of MuseScore?

Reply

• Mar 29, 2016 - 08:35

I can reproduce with a nightly build on windows 8. I can also reproduce on mac osx with a release build (I can't with a debug version).
Here is the trace...


0 org.musescore.MuseScore 0x000000011026e9ac Ms::ScoreView::adjustCanvasPosition(Ms::Element const*, bool) + 1212
1 org.musescore.MuseScore 0x0000000110507391 Ms::Score::pasteStaff(Ms::XmlReader&, Ms::Segment*, int) + 10705
2 org.musescore.MuseScore 0x0000000110269c11 Ms::ScoreView::cmdRepeatSelection() + 1185
3 org.musescore.MuseScore 0x0000000110265417 Ms::ScoreView::cmd(QAction const*) + 16071
4 org.musescore.MuseScore 0x0000000110168eb7 Ms::MuseScore::cmd(QAction*, QString const&) + 4135
5 org.musescore.MuseScore 0x0000000110167ac4 Ms::MuseScore::cmd(QAction*) + 900
6 org.qt-project.QtCore 0x0000000115fa07d2 QMetaObject::activate(QObject*, int, int, void**) + 2994

Reply

• Mar 29, 2016 - 14:36

I know there were quite a few bugs fixed over the past couple of years where there would be a crash that happened on some operation involving mmrests but only if the mmrests were already present when the file was loaded - you had to save and reload the file after creating the mmrests to see the issue. And the cause in pretty much all of those cases was, the underlying measures has a null system (they had never been laid out) and somewhere we didn't handle that correctly. As far as I know, the fixes were all to make sure we *do* handle null system correctly, because there is no meaningful value we can give system for measures that have no been laid out. So clearing the system of the underlying rests in these cases too *should* be ok, I think - we *should* be handling that OK now.

Reply