Crash on saving results in complete data loss (Version: 2.0.2, Linux)
Reported version
2.1
Priority
P2 - Medium
Type
Functional
Severity
S1 - Blocker
Reproducibility
Randomly
Status
active
Regression
No
Workaround
No
Project
On saving the document the application crashes, leaving behind an unreadably empty file. This happens rarely and since it results in complete loss of the data I was so far unable to reliably reproduce it.
In my opinion this is a major conceptual bug: Saving the document should be an atomic operation where, if the application crashes at any point, the state of the document is well defined. It is also a major issue since you irreversibly lose the whole document, which may be hours of work (depending on the time of your last backup).
I attached the resulting corrupted file in case anyone can draw any information from it.
| Attachment | Size |
|---|---|
| 58_Elephants_Foot.mscz | 171 bytes |
| 58_Elephants_Foot.mscz, | 11.24 KB |
Comments
Which OS are you on?
See #63271: Changing instrument names may lead to crash and empty mscz file. It's possible you are seeing the same issue; certainly the symptom is similar. Unfortunately so far no one has figured out a way to duplicate this.
I'm on Linux, too – forgot to mention that – so there might be a common cause. However in my case it always happened when I was saving the score. Also, I had linked parts and it could be that I had just deleted on of the piano staves (just because that's mentioned in the other issue).
Anyway, finding and fixing the cause of the crash is one thing. What is much more important in my opinion is to make sure that any crash cannot lead to a complete loss of data. More frequent updates of the backup file would be a good starting point, in my case it was from when I had just started and thus also contained a basically empty score.
I added a feature request #87101: Make saving an atomic operation, which may help to (1) prevent the loss of the data and (2) reproduce the issue.
As I mentioned in the other issue, do note that a crash while saving shouldn't lead to much loss. MuseScore auto-saves every two minutes by default. After a crash, you should always have an auto-save available and MuseScore will offer to recover from it next time you start.
Could you explain how it is possible that both the file itself as well as the auto-save become corrupted at the same time? Also, where do the .<score_name>.mscz., files come from and why aren't they kept up-to-date?
The auto-save should never become corrupted at the same time as the file being written. Are you seeing a case where it is? In the same way? I guess if the crash happens while writing the actual score, the auto-save should be fine, and if the crash happens while writing the auto-save, the actual score should be fine.
The file you mention with the period and comma is not an auto-save but a backup created on the first save of any given editing session. It records the state of the file when you opened it, and serves as a baseline. The auto-save would always be more recent.
From my brief experience with MuseScore and these forums, it seems like there is some confusion about the location of the autosave files. This page gives the location for each OS.
https://musescore.org/en/node/52116
Also, the autosave files do not have the same name, but rather some random name like "scGz6095.mscz"
Thanks for your comments, now it understand the different backup files better. There actually were quite some auto-save files from older sessions but unfortunately none form this crash. This is somewhat strange, shouldn't there be the auto-save file left after the crash? (I do have auto-save turned on.) Next time such a crash happens I will be more aware of what to look for so hopefully I will be able to provide more useful and detailed info.
I thought I had tracked it down, but maybe not: Got another crash with emtpy score afterwards but this time I could restore the previous state using Dropbox. When I repeat the same actions I again get a crash but this time WITHOUT loosing the score. Instead there is a "temp" file that wasn't there on the first crash. Here are the steps to reproduce:
(1) Open the file with MuseScore
(2) Delete Staff 2 of the Hammond Organ via "Edit" --> "Instruments..."
(3) Save the file.
For me this produces a crash (on saving, not on deleting the staff). The original file is untouched (same md5sum) while the additional file (with same name plus ".temp" appended) is basically empty and cannot be read by MuseScore. The difference to my first crash is that I did NOT have that temp file but instead the original file looked like the temp file does now. Also, when I restart MuseScore it asks to restore the old session and is able to do so without errors while on the first crash it also asked but then was NOT able to read the corresponding file.
Hope this is of any help :-)
Ok, steps to reproduce the original crash (with loss of data):
(1) Open the file with MuseScore
(1a) Change something in the score (enter/delete some notes)
(1b) Save the score
(2) Delete Staff 2 of the Hammond Organ via "Edit" --> "Instruments..."
(3) Save the file.
This should result in the behavior describe above for the first crash (i.e. no temp file and empty—180 bytes—score).
Steps given in #11, on my system (Linux Mint 17.2), result in a SIGABORT at line 505 of function
Staff::write(Xml& xml)in filelibmscore/staff.cpp.As I understand it, the problem is that the separate part for Hammond now has 1 staff, but bar lining still assumes two staves. At some point after removing the second Hammond staff, the bar line span should have been adjust, but it has not.
Which makes me think this is another manifestation of #63226: Crash on autosave after deleting staff from instrument in score with linked parts
Yes, it sounds like the trigger for the crash is the same. But here we additionally have the issue with the zero-length score. It could be that a crash caused by a different problem may also result in zero-length score. I think this should be treated as separate issues.
might relate to #271185: Scores corrupted beyond repair, containing nothing but zeros