Mscore crashes when toggling visibility instruments in "edit", combined with hiding empty staves.
MS Windows 10, Musescore 2.03
Hi,
In the score attached (as in some other scores as well) there seems to be some bug, causing Mscore to shut down.
It happens (at least, thats one way to reproduce the crash) when, after first creating multiple rests and/or hiding empty staves, I use "edit" and "instruments" to hide the first instrument (in this case called "solo").
I tried to do it the other way around, but with the same result: Mscore shuts down.
During the process of editing any score I quite often toggle between the visibility of instruments, with no problem at all and in this particular case the problem also at some point unexpectedly occurred.
Could you please help me out on this.
Thanks and regards.
| Attachment | Size |
|---|---|
| 203 Lullaby.mscz | 41.31 KB |
Comments
current debug build from master branch crashes right on opening that score
Fatal: ASSERT: "minTick > 0" in file ...\MuseScore\libmscore\measure.cpp, line 3317 (:0, )
The score appears to have a subtle corruption, or at least something unexpected that is causing problems. Actually, two things, both in the top staff: the "p" in measure 70, and the "poco rit" in measure 96. In both cases, these appear to be attached to places where it shouldn't have been possible to attach a dynamic, and somehow this was either not stored properly in the file, or it isn't being read correctly. If you have insight into how those problems occured, please share.
However, I cannot reproduce a crash from this, except that indeed, the bad dynamic markings prevent it from loading at all in the experimental builds for 3.0. Deleting the dynamic markings (using 2.0.3) and re-saving allows the file to load.
Can you give precise step by step instructions to reproduce the crash in 2.0.3?
BTW, I have unassigned you, as the "Assigned" field is for the person who will *fix* a bug, not the person who reported it.
Thanks for looking at the score.
After getting rid of the corruptions you've pointed out (is there a way to track those?) copy-pasted all staves to a new sheet just to be sure. The problem remains. It seems that toggling the visibility of staffs/instruments only and only then causes a crash when creating multimeasure rests.
Or, to be more specific: when using multimeasure rests (style/score), hiding instruments (edit/instruments) AND (not or) hiding empty staves (style/score) causes Mscore to shut down.
After some trial and error:
Exporting it to .xml and opening it again seems to solve all problems without too much loss. Only the visivility of all elements are set to "on" again.
That's interesting, but we still need precise step-by-step instructions to reproduce the problem - preferably starting from the fixed (not corrupted) version of the score.
I tried the following:
1) Press "M" to enable multimeasure rests
2) Style / General
3) Enable "Hide empty staves"
4) OK
5) Press "I" to display Instruments dialog
6) Uncekc "Visible" for top staff
7) OK
This is my best attempt to do what I think you are describing, but there is no crash for me. Are you doing something different?
Here, BTW, is the fixed version of the file I used:
Yep, that's exactly what I have been doing.
I just opened the file you sent me, thanks.
Interesting enough, Mscore does not shut down immediately*, as it did before, but when hiding staves, it is using a lot of processing capacity (14% instead of the usual 0,5%). If I unable "hide empty staves", everything is back to normal.
1) I download file and open it
2) Press "I" to display instruments dialogue
3) Uncheck "visible" from top staff (the only one which seems to cause problems)
4) Task manager indicates MS using 0,0-0,4% processor capacity, which is normal
1) Download & opening file
2) Style/ enable hiding empty staves
3) Taskmanager indicates MS using a continious 14,5% processor capacity.
4) causing the program to slow down a lot
5) Style / disable (or is it unable) "hiding empty staves"
6) Taskmanager indicates MS is back to 0,0-0,4% processor capacity.
1) Download & opening file
2) Style/ enable hiding empty staves
3) Taskmanager indicates MS using a continious 14,5% processor capacity.
4) causing the program to slow down a lot
5) Press "I" to display instruments dialogue
6) Uncheck "visible" from top staff (the only one which seems to cause problems)
7) Taskmanager indicates MS is back to 0,0-0,4% processor capacity.
So, still something is wrong here, and my guess would be the problem is somewhere hidden in the staff of the first instrument, and then, ONLY if it is displayed on screen, because if I delete the "solo", I don't see any above average use of the processor, whatever commands I use.
When I use your sequence everything seems to be OK, by the way:
1) Press "M" to enable multimeasure rests
2) Style / General
3) Enable "Hide empty staves"
4) OK
5) Press "I" to display Instruments dialog
6) Uncheck "Visible" for top staff
7) OK
I suggest I let it go for now, since after using the xml work around my score seems to be OK, but if on other scores the problem recurs, I would be grateful to be able to contact you again.
Thanks for helping,
regards
* it did in the end, though, but after a lot of doing and undoing "I", "M" and "style/score/hiding empty staves".
** update: if, using the score you send me, without using any further commands, but just enabling "small staff" in the piano staff1 "staff properties", task manager indicates normal processor activity. But if I also put staff2 to "small", task manager indicatues very high processor activity, not going back to normal. If i put the top stave to "small" (so only the 4 choirstaves are normal) the processor activity goes back to normal again. Shoot me ;-)
***update 2:
looks like "layout/pagesettings" has got some influence here. For most of my scores (and in this one) I use l/r/t/d = 7/7/10/10, to get the max out of a sheet. If, using your score, I put it back to default 10/10/10/20, whatever I try, everything seems to go normal, without any higher processor activity. Which brought me to try "continious mode" WITHOUT resetting page margins to default 10/10/10/20, and then, as expected, also functions normally. So I guess Musescore might have some problems in figuring out how to fit the staves on the pages. And in some cases, the program slows down and sometimes (when processor activity exceeds ca 15%) shuts down. I think this, more then any of the above, may be a valuable clue to solving the riddle.
I still can't reproduce any sort of problem. From your description, though, I can guess there is some corner case floating round-off error where some calculation is working out to some value like 3.999999 and there is a comparison against 4.0 that sometimes goes one way and sometimes goes the other and this is giving MuseScore fits. That would explain why changes in scaling would solve it - all calculations are now different. Also explains why it is system dependent - floating point calculations tend to be hardware-specific. But that's just a theory.
I can open the initial score in current master, but cannot reproduce the crash. CPU consuming is adequately corresponds to the operations.
In reply to I can open the initial score… by Anatoly-os
It has been fixed 2 years ago?
Thanks anyway :)
Automatically closed -- issue fixed for 2 weeks with no activity.