Crash / corruption on copy/paste with end segment in mmrest

• Aug 28, 2015 - 17:07
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

Ubuntu 14.04, GIT commit: d073c1f

I am seeing a few related behaviors that all seem to stem from confusion over the end segment in a selection. Ideally we could find one common spot to fix these, but I suspect it won't be that simple.

Here is a corruption:

1) load attached score
2) click measure "B" in top staff to select
3) Ctrl+Shift+Right to extend selection to next mmrest
4) copy
5) click measure "B" in bottom staff
6) paste

Result: measure "C" is now corrupt in bottom staff - contains a "long" note and two "long" rests, all set to negative durations.

Now to see a crash:

1) load attahced score again
2) replace measure C with two tied quarter notes
3) repeat steps 2-6 from above

Result: crash. The crash comes read an end spanner tag, and apparently the tie it applies to has been deleted at this point because of https://github.com/musescore/MuseScore/blob/f07d7bb52b8492917198a87a653…. But this makes no sense, there is no reason we should have been looking at this tie in the first place.

The underlying problem in both cases is, I think, that the end segment for the selection is not being set well, or not being treated correctly when doing the copy. Presumably it's confusion over whether to use the segment in the underlying measure or the mmrest. BTW, the problem does not go away if you toggle mmrests off then on again before starting - it has nothing to do with the fact that the underlying measure has not been laid out yet.

You can see a much less serious but visually instructive symtpom of the same problem as follows:

1) load attached score
2) click measure "A" in top staff to select
3) copy
4) click measure "A" in bottom staff
5) paste

Result: the paste itself goes fine, but the selection extends to the end of the score rather than just being the one measure. Variations of this can show different anomalies.

Attachment Size
mmrest-selection.mscz 6.19 KB

Comments

• Aug 28, 2015 - 17:21

Here's a picture of the corruption, BTW. This is after trying to copy measure "B" and the following mmrest from the top to the bottom staff. Note everything to the end of the score is selected, and measure "C" is badly corrupted in the bottom staff even though it should not have been involved:

copy-mmrest-1.png

Reply

• Aug 28, 2015 - 19:53

Not sure that the investigation will be useful because I notice corruptions in three different forms (the last, there is one year). It is a corruption that has evolved over time ... :(
But as I watched, I share!
The starting point is this file: File test.mscz
First.jpg

- In May 2014, with this Nightly: 56177c3
after copying and pasting the first measure and the following mmrest (first staff) in the second staff, I receive this result (with a whole rest, half rest and quarter rest in the following measures, non mm rests.)
19 mai.jpg
- In June 1014, with this Nightly: f031e87
I get this (the C quarter note - or the first measure - is duplicated in the following measures)
7 juin.jpg
- Last step (and it is the current result), on August 6, 2014, with this Nightly: aa7957b
I obtain (a corruption more "spectacular")
6 août.jpg
After seeing, I am not sure at all, but the last change is possibly here? https://github.com/musescore/MuseScore/pull/1089/files

Reply

• Aug 28, 2015 - 19:57

Thanks, I was hoping to see your investigation to give me an idea of places to look.

I've found where things actually go wrong; it's here:

https://github.com/musescore/MuseScore/blob/f07d7bb52b8492917198a87a653…

This is the code that copies elements to the clipboard one by one, stopping when we reach the end of the selection, but if the end of the selection is within an mmrest, may will miss that, depending on how the end of the selection was recorded.

I am not sure of the best way to fix this. The safest thing to do, if we think things are basically OK elsewhere, is probably to check to see if our end of selection is in an mmrest, find the corresponding segment in the underlying measure if so, and stop if we reach either of those segments. This should fix the issue with no other side effects.

But maybe we *want* other side effects - maybe how we record the end of the selection is not as consistent as it should be right now, and we could improve on this by really deciding how we want to handle the start & end of selections with respect to mmrests, and going through the code everywhere to be more consistent. This might fix other problems too. But that would be a bigger task, and the attempt would likely cause as many problems as it fixes until we finally get it right.

I think for now I will propose a PR that contains the safe fix for the corruption/crash as well as a hopefully similar fix for the incorrect selection after the paste. If others want to pursue the potentially bigger changes I mention, that would be fine, but I think there is no hurry if we don't know of anything else that is seriously broken.

Reply