A particular MSCZ file causes crashes.
Reported version
3.4
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
duplicate
Regression
No
Workaround
Yes
Project
The MSCZ file appears to have been corrupted in a way which MuseScore does not detect, but cannot handle.
1) Open MuseScore
2) Load Hair_Medley-3
3) Try to save it (or, I suspect, wait for autosave). MuseScore will crash. (I have send at least two crash reports.)
Much time has been put into this arrangement. I would appreciate some way to recover my work, even if I have to lose some measures to do so.
| Attachment | Size |
|---|---|
| Hair_Medley-3.mscz | 425.49 KB |
Fix version
3.5.0
Comments
It is true that version 3.4 cannot handle this type of corruption, but version 3.5 can handle such a score. Release builds can, that is, and that includes the alpha and the beta. It will still trigger a failed assert in debug builds, though, but that is on purpose.
By the way, the suggested method for recovery in cases like this is usually to delete all parts and recreate them. Of course, this means that all work spent tweaking individual parts will have to be done again, so hopefully you won't have spent too much time on that.
I was able to recreate the score. I recovered most of the measure framework (global things like time and key signatures, tempos, etc.) from the MuseScore 2 version. I then copied the parts across. I think the problem may be in Trumpet 1 measure 266, where I had starting to add to the score before my last successful save of that score. However, the crash when trying to recover the full trumpet data in one copy-paste may have been a coincidence.
In any case, I have recovered my data at the cost of a few hours work. (My operation was to copy some and quickly exit the bad version before MuseScore would decide to try saving that unchanged score.) I have downgraded from Critical to Major. However unlikely that this will affect another user, if it does, then it will likely be critical to that user.
Aaron
In reply to It is true that version 3.4… by mattmcclinch
@mattmcclinch
I look forward to 3.5. For now, I'm not ready to try the pre-releases. Once I'm fully retired as a programmer, I'll try to volunteer to work on MuseScore and work with the beta and, possibly an alpha.
I've found many problems with dealing with parts, though the most egregious is that MuseScore appears to try to update all the parts in real-time instead of as a background process. I usually don't create the parts until after I've finished the score. I made an exception with the medley for a valid reason, but I was still considering deleting them until I was finished. This gave my a good reason to not have the parts getting in the way.
Thank you,
Aaron
Indeed no crash in 3.5
Indeed a corrupt path, the 1st, Alto Sax I
As mentioned earlier removing and regenerating it fixes the crash in 3.4.2 too, see attached (recovering took less than a minute)
That in turn is a duplicate of #292064: Crash on save of a score with corrupt parts