Hang/crash by copy-paste all a system of linked staves containing lines
GIT commit 4f8cd13 / Windows 10
I do not know if this is "the cause," or a cause, or a variation of other related issue. Anyway, I can reproduce rather easily, all these messages appearing when MuseScore can not open a file:
These bug reports are more numerous on the forums, for example, inter others:
- https://musescore.org/en/node/90211
- https://musescore.org/en/node/102541
- https://musescore.org/en/node/56956
- https://musescore.org/en/node/89781
I am able to reproduce from scratch those failure messages. Eg with two new files created the last few minutes:
- test 2.mscz
- My_First_Score.mscz
How? The problem occurs in a score with several linked staves (and it is tenfold if you add parts), and by copy-paste several lines (except Voltas which appear only on the top staff).
The main point, and this is perhaps the mistake committed by users (?) is that, to reproduce this issue, you must selecting not only the first staff (which would sufficient, since the staves are linked) but ALL the system of x linked staves. Ie:
So, for reproduce:
1) My First Score
2) "I" -> Add 5 linked staves
3) Add eg a crescendo in the first measure, a decrescendo, a trill line and a pedal line in the following measures, or open this test file: test.mscz
4) Select ALL the system (the first four measures for the six linked staves)
5) Press R key 3 times. If works always (not really hanging), press R key a fourth time. From
here, the programm is hanging (eg click on it to accelerate the process if needed)
However, from here, it is possible (not always) after a long time to wait, to "save as" the score.
Then, when you close the page with the "X", you receive "really" the crash. And when you want reloading the file, you get a failure, as described above.
Comments
Press R key 3 times
When you do that, you are creating 6 crescendos, 6 decrescendo etc... on each line.
Next time, it's 12. The third time 24 I believe and so on and so forth...
Yes, of course. The question (and if this issue is related? EDIT: I wanted to say: this issue related to other issues mentioned above) is to know if all users have understood this?
And instead to copy-paste (via R key) only the top linked staff, they make a copy-paste for all the system?
When I follow these steps, I see a whole bunch of error messages logged to the console from Spanner::removeSpanner() about not being able to find the spanner to remove. Looking up the call chain, I see this was being called by Spanner::setTick(), which is marked with the comment "Do not call from within a loop over spannerMap". I remember this change, it was made here:
https://github.com/musescore/MuseScore/commit/255ce35cd87d3a3b93e505736…
I don't see that we are actually looping over spannerMap here, but somehow, this code is still failing, not sure why. PResumably it relate to the links, though.
Fixed in branch master, commit 264ce26c89
fix #102571 Hang/crash by copy-paste all a system of linked staves containing lines
Fixed in branch master, commit 9549474d3f
Revert "fix #102571 Hang/crash by copy-paste all a system of linked staves containing lines"
This reverts commit 264ce26c89eeb5bb8ec558a45e5b54ff866b6193.
The same behaviour is in MuseScore 2. The workaround is to copy only one linked staff which automatically generates all elements.
FWIW, though, the issue with this particular crash completely destroying the file (leaving it filled with zeroes) - maybe that is actually improved by dmitriy95 changes of late?
Starting from version 3.1.0 this procedure doesn't produce duplicated lines anymore. Not sure what exactly fixed this though.
Automatically closed -- issue fixed for 2 weeks with no activity.